Recent searches
No recent searches
Update User/Customer object via API
Posted Jan 17, 2024
Hello! I am looking for some best practices/guidance on how to best solve for the below:
I want to update the Zendesk User/Customer object via the API. The update will pull in data in custom fields, such as Subscription Plan (free/paid), Last Payment/Renewal Date, Link to Internal System to the user's profile. The purpose of this is to enable accurate reporting of metrics depending on Subscription plan & efficiency gains for agents.
The reporting is done on the ticket level, so it will need to reflect the subscription plan of the user at the time the ticket was created. To achieve that I might add a tag to the ticket at the point of the ticket creation or update a custom ticket field.
We got several millions of users, and there can be multiple updates on their Profile, which can pose challenges on how we handle the update via the API. We also have a Fivetran API connection as we are doing our reporting on Tableau. Here are my thoughts:
- Solution 1: Import all customers and their data into Zendesk, and subsequently add new users as they get created in our system AND update existing users as and when any of the details above get changed.
- Risk: I can easily see us reaching our API limits (700rpm), but also, not all user data imported will be usable/relevant
---
- Solution 2: Import only Paid customers and their data into Zendesk, and subsequently add new users as they get created/upgrade in our system AND update existing users as and when any of the details above get changed.
- Risk: The absence of a Free user might create confusion as to why there are no details in their profile, and missing out on efficiencies from giving agents the ability to just click on a link to view their 'internal' profile.
Also, in the future we might want to add SSO on our Zendesk hosted help centre, using our app's login service - in case it has any bearing on what would be the best approach here.
Has anyone done something similar, and how did you solve for this?
Thanks a lot!
1
3 comments
Austin Killey
Hey Yannis!
Hope it's cool if I throw in my two cents here. Reading through your first solution, that sounds JUST like what an SSO setup could do for you and your team - and sure enough, you called that out right at the very end 🙏
By using user field mapping and provisioning like with SSO, you absolutely could map external user fields that live in another system (Azure, Okta, etc) and tie them to custom user fields in your Zendesk account. This is also how our Salesforce integration does its thing, by tying Salesforce contacts to Zendesk users, Salesforce Accounts to Zendesk organizations, and then updating those Zendesk items whenever the associated Salesforce item changes or a new one is created.
For the initial bulk import, your team could drastically cut down on the number of API requests needed by uploading a CSV file of user data (up to 1,999 users at a time).
From there on, you called it: Any newer users beyond that point could be created, and any existing users could be updated by pointing towards our Create Or Update User endpoint.
Since your focus here is on reporting at the ticket level, I think you're right on the money by tying user fields to ticket fields - dropdown, multiselect and checkbox types will be the easiest to match since they operate based on tags, so any tags associated with user fields will also get used by the ticket when the ticket is first created.
Lots to throw at you here, but I think that what you have in mind is completely doable. Really good questions here Yannis - let me know if anything else comes to mind 👍
1
Yannis
Hey Austin Killey! Thank you for your time to write this up, really appreciate it!
So, just to recap:
A few follow-up questions:
Thank you! :D
0
Austin Killey
Always a good time to ask questions Yannis, you bet:
1. You could do either, or both! The default SSO behavior is automatically creating matching Zendesk user profiles when someone is signing into your help center for the first time but also has an existing user profile in your SSO provider.
2. Yeahhhhh, something like 3 million users spread across 1,999 users per CSV puts us at 1,500 CSVs that would need to be made 😬 Oh hell no..
You called it: API would be the way to go here - and even though you can only fit 100 users in a single Create Or Update Many Users request, finding a way to script this all out or have it done automatically by some other process (like SSO) would be ideal for sure.
If you're able to "chunk" or batch out these requests over a larger period of time, you and your team should be able to easily stay under the rate limit. Important to note: Your overall limit would be 700 requests per minute, but for any endpoint that kicks off a job (basically any endpoint with the word "Many" in it), there's a job limit of 30 active jobs at the same time. Just as long as one of those jobs finishes doing its thing, you can start another job-based request immediately afterwards.
3. So this is a tricky question.. (mostly because our product teams like using the same names for just about everything): For Zendesk user profiles, the ones you and I are familiar with, there isn't a maximum limit for how many users you can have in your account.
In the Zendesk language, "objects" are something that we'll typically associate with custom objects (which contain custom object records). Custom objects and custom object records DO have maximum limits: 50 objects for your account, and 50,000,000 custom object records (50 million!).
Users do count toward your account's overall storage, and you and your fellow admins are able to track that usage at any time in the Admin Center here. User profiles honestly don't take up all that much space on their own, and the true space eater will usually be the accumulating pile of ticket attachments in closed tickets.
Great questions as always Yannis - keep us posted if you think of anything else!
0