Organizations are simply a collection of users in Zendesk (much like groups). We use them to also store metadata (synced from Salesforce), which is used to determine such things as SLA, ARR, etc.
Organizations in Zendesk are created automatically through our Salesforce and Zendesk integration (as well as the GitLab built sync script). This integration allows agents to see a customer's full Salesforce Profile within a live ticket in Zendesk. You can read more about what information we send to Salesforce and what fields are populated with information from Zendesk in the Support Ops handbook.
Please do not manually create organizations. This can break the ZD<>SFDC integration and cause users to receive incorrect SLAs. If you notice an organization needs to be created, please notify support-ops to rectify this.
|Field Named||API Name||Data Type||Possible Values|
|Account Type||account_type||Dropdown||Customer, Former Customer, Prospect|
|Support Level||support_level||Dropdown||Starter, Premium, Ultimate, Basic|
|Technical Account Manager||technical_account_manager||Text||*|
|Number of Seats||seats_decimal||Decimal||*|
|AM Project ID||am_project_id||Text||*|
As a lot relies on organizations being setup properly, this feature requires admin level abilities currently. If an organization needs to be edited, an issue should be filed using the Add Zendesk Organization Notes or Tags Request issue template.
If you notice an organization in Zendesk contains outdated information or the information doesn't match what Salesforce is displaying, this would indicate the sync integration has hit an issue. Luckily, we have the GitLab built sync script that runs every hour to rectify such issues.
In your due diligence, you would want to create an issue via the support-ops-project so support-ops can double check to ensure there is nothing blocking the sync.
All organizations have the ability to have notes about them via the Organization
page in Zendesk. These notes are automatically placed on a ticket (along with
other organization informaiton) as soon as the ticket has an organization
present. This is done via the
Ticket::Internal Comment::Organization Info trigger.
This is an edge case Support-Ops and Sales-Ops are working on. The current solution is to apply the correct tag to the organization so it will get multiple plan tags on newly created tickets. As an example:
Jason Enterprises has a Gold subscription and a Starter license.
Salesforce has them as Gold, so the organization in Zendesk shows their GitLab Plan as Gold.
To ensure they get the proper support (and the ticket routes properly), we need to manually apply the starter tag on the organization.
Support engineers can request tags and notes be added to the org.
Once a ticket comes in, it may show in multiple views. The non-applicable tag needs to be removed so that it only shows in a single queue.
By default, organizations are setup so that the users within it can only see and comment on their own tickets. This security measure often doesn't work for some organizations though.
Because of that, we have the ability to setup Shared Organizations, a term meaning the users in an organization have heightened permissions and can do see and/or comment on tickets that are not theirs. For more information on Shared Organizations, review the Shared Organizations workflow.