What is your goal?I’m trying to update a Sharepoint list, with a webhook
What is the problem & what have you tried?I can create list items with webhooks from another system, but can’t update the list items without the item ID. The item ID is autogenerated by Sharepoint, it is not in the data that I get from the webhook. I can’t identify the item by other fields.
Hi @Rattila
A couple of suggestions:
Use sharepoint’s Make API Call module to search based on some webhook info that uniquely identifies your item. For the list of available endpoints, refer to the SharePoint API in Microsoft Graph Documentation.
Use HTTP module to query sharepoint’s REST API.
Keep a side control of IDs based on the item’s info on Google Sheets or Airtable. I don’t really recommend that as it’s too complex to maintain.
Hello @Rattila and Welcome to the Make Community!
Can you please share some details about how your scenario works?
If you want to use a Make Webhook to update a SharePoint list item, but you want to pass in the Item ID (even though you don’t know it), then you must have another way to identify the item you want to update.
You could try using a Data Store to store the item ID when you create an item.
If your source system has an ID of its own to identify an item, store that ID along with the item ID from SharePoint when the item is created.
When the scenario runs, and you’re updating an item instead of creating, then look up the item ID based on the source system ID in the Data Store first.
Hope that makes sense and hope it helps!
Thanks for the replies. Using a datastore seems like a workaround, but it adds two extra steps. Frustrating
You previously stated you cannot identify the item via any other details.
For that reason, you need some way to store a reference between an item in your source and an item in SharePoint. This isn’t a workaround, it’s just necessary.
We may offer up some more direct approaches, but we’d need additional information about your scenario/workflow, webhook contents, etc…
Yes. Besides that, as I stated on #3 in my previous answer, you have to maintain it, meaning creating, updating and deleting the side records. I don’t think it’s a good idea.
Try querying Sharepoint by some uniquely identifiable field you do have.
When you create the item in SharePoint, store the id of that item from the external system in that new SharePoint item. Then you don’t have any separate table to maintain.
Then you have to maintain not one, but TWO side controls AND keep them in sync.
After a while, you’ll be creating whole Make scenarios just to enforce consistency on this data store.
Besides, there’s no guarantee that the sharepoint record won’t be deleted or messed up with externally to Make.
Hi,
I’ve done exactly that when I set it up, but it’s useless as I can only identify the item by the autogenerated ID columns. I’m not even sure how I could export that ID data, as I cannot access any data in a SharePoint list without the ID. It feels like I’m missing something here
You probably can, otherwise you also can’t send an update request to the webhook.
Think about it like this: you enter a library and ask the librarian: “I want a book”.
Does it make sense? Only if you want ANY book from the library.
What if you ask: “I want Twenty Thousand Leagues Under the Sea, by Jules Verne, xth edition.”
You just uniquely identified the book without needing to know the internal classification code of the library.
If you even believe you could create the said data store to map sharepoint ids to some info you get from the webhook, that SOME INFO is what uniquely identifies your record, otherwise your data store is useless..
Use what you have and query sharepoint’s REST API. Use the returned ID just for the mappings on subsequent modules.
Thus, if you have the info that uniquely identifies the record to be updated, the data store is useless. If you don’t, then the data store is useless.
Hi Damato,
Thank you for your reply. I know you are trying to be helpful, but it does sound a touch patronising. That library reference was not necessary.
If I want to update or get a SharePoint item, I need to specify the ID, which I do not have. There aren’t any other fields I can map. I have done quite a few scenarios in other modules, and I was able to choose another field that I have.
I cannot do that in SharePoint, that is why I was asking if anyone had come across this before. I can probably use HTTP GET query a list, map the ID column, and then use that. It adds two extra steps, though. When you want to process thousands of items, these steps do add up. It’s very frustrating when there could be a much simpler solution, unless I’m missing something
Sorry about that. It was not my intention.
I just thought you could use a clear analogy.
Hello @Rattila,
When it comes down to it, it seems like you’re building something of a one-way sync.
You can use SharePoint Make an API call to search your lists by a specific field.
That specific function is not currently available in the built-in SharePoint modules which is why Make an API call is available for use.
I feel like the best compromise here is to just create a Data Store and build around that until you can put a better solution into place.
If you have to add an item, it should use about 4 credits.
If you have to update an item, it should use about 3 credits.
Let’s say you have to update an item but you’re able to easily search SharePoint list fields to find it…
You’re still using 3 credits, it’s just easier to develop and use Data Store rather than figure out how to search SharePoint Lists by field values using custom API calls.
It’s not that difficult. It’s a Data Store with one column, the SharePoint list ID. The key is the key from the external system (assuming each item has a unique key).
OP is essentially building a custom one-way sync, and these are the nuances of it. OP gets to decide exactly how to handle all cases within the limits of the systems involved.
If a SharePoint item is deleted and the external system triggers an update, then the item can be re-created in SharePoint or ignored and the Data Store reference for it can be deleted. The maintenance is built into the scenario and don’t need more scenarios to maintain the Data Store.
