Syncronize Zendesk with in-house custom application to load user data. | The place for Zendesk users to come together and share
Skip to main content
A
Anton13
Newcomer
August 14, 2025
Solved

Syncronize Zendesk with in-house custom application to load user data.

  • August 14, 2025
  • 2 replies
  • 73 views

Hi,

 

We have in-house application where we store information about customers that were want to add to Zendesk:

- License type

- Customer creation date

- Product version

and some other product related parameters.

 

This in-house application has API which can be utilized to pull information.

 

Some information is just important to display for agents like Product Version so they can search for relevant information in knowledge base, like whenever bug is fixed/not for example. 

Other information can be used for triggers/automations, like for example set high priority for customers with enterprise licenses.

 

I believe there are multiple ways to achive above:

1. Ticket fields + Zendesk Action Flows: it allows to use API to make a request on ticket creation, get the data and update the ticket:

- It should be easy to implement, as it does not require any development except configuring Action Flow.

- It allows to have infromation and act on that with triggers/automations, such as license type for example.

 

2. Zendesk Custom Objects:

- It is more expensive option, which would require efforts from engineering side to regularly sync customer info from in-house app to Zendesk.

- It allows to sttore infroamtion in tickets and act on that, there is EAP for reporting also.

- In addition to previous option it also allows to integrated those with ticket form: i.e. allow customer to select their license if they have many.

 

My question is: 

1. Are there any procs/cons I'm missing?

2. Are there might be other ways to achive the above I'm also missing?

 

 

    Best answer by Ruben14

    Great breakdown, @anton14 . A simple mental model I use is “display vs. operate.”

     

    If you mostly need agents to see product data, Custom Objects + lookup relationship fields give you a native UI, durable storage, and clean relations to users/orgs/tickets; you can surface version/license right on the ticket and search/report on it without doing real-time calls on every ticket create.

     

    This is usually my default because it scales, is cacheable, and avoids introducing ticket-creation latency or brittle runtime dependeencies on your in-house API (https://developer.zendesk.com/documentation/custom-data/v2/creating-custom-objects/)

     

    When you need the data to drive automation quickly, it’s still safer to sync into user/org fields or a related custom object on a schedule or event (user created, org changed, nightly job) and let triggers work off those stored values. Calling out synchronously at ticket creation via Action Flows or webhooks is tempting, but you’ll want to guard for timeouts, retries, and rate limits; if you do it, cache the response into fields so subsequent tickets don’t re-fetch. 

     

    For forms where a requester might pick among multiple licenses, lookup relationship fields on the ticket form can populate and validate against your object rather than free-text, which helps downstream analytics and rules 

     

    Two extras I’d consider in your pros/cons:

    • 1) backfill and rebuild strategy, Custom Objects make reprocessing easy when your source model changes
    • 2) reporting COs now play well with Explore, while trigger-time lookups don’t. A hybrid is common: scheduled sync from your app > Custom Objects/User fields for truth, then optional Action Flow on ticket create only when a field is missing or stale. If this helps, feel free to mark it as the answer so others can find it later.

    2 replies

    Ruben14
    Ruben14Answer
    September 17, 2025

    Great breakdown, @anton14 . A simple mental model I use is “display vs. operate.”

     

    If you mostly need agents to see product data, Custom Objects + lookup relationship fields give you a native UI, durable storage, and clean relations to users/orgs/tickets; you can surface version/license right on the ticket and search/report on it without doing real-time calls on every ticket create.

     

    This is usually my default because it scales, is cacheable, and avoids introducing ticket-creation latency or brittle runtime dependeencies on your in-house API (https://developer.zendesk.com/documentation/custom-data/v2/creating-custom-objects/)

     

    When you need the data to drive automation quickly, it’s still safer to sync into user/org fields or a related custom object on a schedule or event (user created, org changed, nightly job) and let triggers work off those stored values. Calling out synchronously at ticket creation via Action Flows or webhooks is tempting, but you’ll want to guard for timeouts, retries, and rate limits; if you do it, cache the response into fields so subsequent tickets don’t re-fetch. 

     

    For forms where a requester might pick among multiple licenses, lookup relationship fields on the ticket form can populate and validate against your object rather than free-text, which helps downstream analytics and rules 

     

    Two extras I’d consider in your pros/cons:

    • 1) backfill and rebuild strategy, Custom Objects make reprocessing easy when your source model changes
    • 2) reporting COs now play well with Explore, while trigger-time lookups don’t. A hybrid is common: scheduled sync from your app > Custom Objects/User fields for truth, then optional Action Flow on ticket create only when a field is missing or stale. If this helps, feel free to mark it as the answer so others can find it later.
    Elaine14
    Elaine14Employee
    Employee
    December 31, 2025
    Hi Ruben,
     
    Thank you for your insightful response and for sharing your mental model of “display vs. operate.” Your explanation regarding Custom Objects combined with lookup relationship fields providing a native UI, durable storage, and clean relations makes a lot of sense for surfacing product data to agents efficiently.
     
    I appreciate you highlighting the scalability benefits of this approach, including caching to avoid latency and runtime dependencies on the in-house API, as well as the detailed link to Zendesk’s developer documentation.
     
    Your advice on syncing data for automation purposes via scheduled jobs or events and letting triggers operate on stored values is very helpful. It’s a practical way to avoid potential timeouts and rate limits associated with synchronous API calls during ticket creation.
     
    The suggestion to use lookup relationship fields on ticket forms for licenses, rather than free-text entries, to improve analytics and validations is also valuable.
     
    Lastly, the two additional considerations about backfill strategies and hybrid syncing approaches round out the picture nicely.
     
    Thanks again for your detailed feedback — I’m sure it will greatly help others exploring similar implementations!
    Terms & ConditionsAccessibility statement