Today, when creating a custom object, the Create endpoint returns an ID that must be used to access the object again. For example, if I create an Order object record with order ID "order-12345", Zendesk will return an object id that looks something like this: 5d0daa84-aec0-11e7-9a70-416881d66b6d. if I later need to update the order with a new status from my system of record, my application must send this automatically assigned ID to the Update Object Record endpoint on the next update.
If I understand this correctly, this requires one of two things from my application:
- I must write the Zendesk object id back to my system of record, so that on future updates, I can check for the presence of the object id and use it to access the object and write the update
- I must maintain a middleware that will store the ID and create a relationship between the order ID "order-12345" and Zendesk object id 5d0daa84-aec0-11e7-9a70-416881d66b6d.
Neither case is ideal if Sunshine is being implemented as a CRM for service that breaks down the silos of data. For example, perhaps my system of record is not extensible and cannot add a "zendesk_id" field, or perhaps the business owners of my system of record are happy to grant read but not write access to the system for some reason. In such a case, I should be able to set a unique ID that corresponds with the ID in my system of record, to more easily maintain the relationship. That way, I can hit the Update Object Record endpoint with the ID from my system of record to send the latest data to the object.
This does open up the possibility for conflicts between user-defined UNIDs in Custom Objects, but it may be worth exploring the trade-offs and seeing if it's worthwhile to build an environment that can allow this flexibility for developers while handling conflicts in the database.
Please sign in to leave a comment.