Plan requirement
| Subscription | Any plan |
| Access | Admin |
Customer data from your CRM beside the ticket. Before you start: the app displays nothing at all until you tell it which objects and fields to show, so a successful installation looks exactly like a broken one.
Connect it
- In Admin Center, click Apps and integrations in the sidebar, then select Integrations > Integrations.
- Select Salesforce and open the Support app tab.
- Connect your Zendesk instance to Salesforce with the appropriate credentials.
- Turn the Salesforce app on.
- Choose the objects and fields to display, and set the role and group restrictions.
- Test with a real customer record.
Zendesk admins and team members in a custom role with the permission can configure this.
Three limits to check before you design around it
| No account hierarchy | The app does not support Salesforce account hierarchy. If your structure depends on parent and child accounts, that relationship does not come across. |
| No numeric fields | Mapping numeric fields is not supported. |
| No custom fields for lookup | Custom user and organisation fields cannot be used to match records. |
Matching has to be exact
Zendesk looks for a Salesforce record where the selected object and field exactly matches the data in the specified Zendesk field. Not approximately, and not case-insensitively in the way people assume.
So a customer writing from a second address shows as unmatched, and an unmatched record looks like a new customer. Check how often that happens with your own data before you rely on the panel being populated.
Decide which system owns the customer
Usually the CRM. Then Zendesk displays and does not overwrite, and there is one authoritative record. Two systems both allowed to update the same field produces silent disagreement, and nobody notices until somebody acts on the wrong version.
Display before synchronising. Showing account details, plan and owner beside the ticket gives agents nearly all the benefit with none of the risk: displaying is a configuration, two-way synchronisation is a project.
Map few fields
What an agent needs before replying: who this is, what they pay for, who owns the account. Ten fields nobody reads is clutter beside every ticket, and it is clutter you cannot unsee once agents have learned to scroll past it.
If you are considering a two-way setup, talk to us first. Synchronisation between systems is where most integration projects go wrong, and it is cheaper to decide what owns what beforehand.
Comments
0 comments
Article is closed for comments.