Dependency Mapping helps you understand how your Zendesk configuration objects are connected. It answers questions like:
- Which triggers use this custom field?
- What will break if I delete this group?
- Which macros reference this tag?
- How do I find all objects that assign to a specific team?
What Dependencies Are Tracked
Configly automatically extracts dependencies from your configuration objects during sync. It identifies references to:
Custom Fields
When a trigger, automation, macro, or view references a custom field:
-
Ticket fields -
custom_fields_12345 - User fields - In conditions and actions
- Organization fields - In conditions and actions
Example:
A trigger condition checks custom_fields_67890 (Product Type), and an action sets custom_fields_12345 (Priority Score). Configly tracks both dependencies.
Groups
When objects reference Zendesk groups (teams):
- Group assignments - Actions that assign tickets to groups
- Group restrictions - Macros or views restricted to specific groups
- Group conditions - Rules that check which group a ticket is assigned to
Example:
A macro is restricted to the "Billing Team" group. Configly tracks this dependency so you know the macro won't work if the group is deleted.
Tags
When objects add, remove, or check for tags:
- Tag actions - Macros or triggers that add/remove tags
- Tag conditions - Rules that fire only if specific tags are present
Example:
An automation checks for the vip tag and escalates the ticket. Configly tracks this dependency.
Brands
When objects reference Zendesk brands (for multi-brand instances):
- Brand conditions - Rules that check which brand a ticket belongs to
- Brand restrictions - Views or macros specific to one brand
Users
When objects reference specific users:
- Assignee conditions - Rules that check who a ticket is assigned to
- Requester conditions - Rules that check who submitted a ticket
Ticket Forms
When objects reference specific ticket forms:
- Form conditions - Rules that only apply to certain forms
- Form fields - Configuration tied to specific forms
Webhooks and Targets
When triggers or automations reference outbound integrations:
- Webhook actions - Triggers that notify a webhook endpoint
- Target actions - Triggers that notify a legacy target
Dynamic Content
When objects reference dynamic content placeholders:
- Placeholder references - Triggers, macros, or automations that use dynamic content placeholders for localised text
How to View Dependencies
From a Configuration Object
When viewing a trigger, macro, or view:
- Look for the Dependencies section
- See all fields, groups, and tags this object references
- Click on a dependency to see more details
Example: Trigger "Auto-assign to billing"
Dependencies:
- Ticket Field: "Product Type" (ID: 67890)
- Group: "Billing Team" (ID: 123)
- Tag: "billing" (used in actions)
From a Field or Group
To find what uses a specific field or group:
- Navigate to the field's detail page (or group page)
- View the Reverse Dependencies section
- See all triggers, macros, and views that reference this field or group
Example: Ticket Field "Product Type"
Used by:
- Trigger: "Auto-assign to billing" (checks field in conditions)
- Trigger: "Tag enterprise products" (checks field in conditions)
- Macro: "Set product category" (sets field in actions)
- View: "Enterprise tickets" (displays field as column)
From the Dashboard
The dashboard shows a summary of dependencies:
- Total dependencies extracted
- Dependencies by type (fields, groups, tags, etc.)
- Most referenced fields or groups
Why Dependencies Matter
Before Deleting Objects
Scenario: You want to delete a custom field because it's no longer needed.
Problem: If triggers or macros reference that field, they'll break when the field is deleted.
Solution:
- View the field's reverse dependencies
- See which triggers, macros, and views use it
- Update or remove those references first
- Then safely delete the field
Impact Analysis
Scenario: You're renaming a group from "Support Team" to "Customer Success Team".
Problem: Macros restricted to "Support Team" will stop working after the rename.
Solution:
- Check reverse dependencies for the "Support Team" group
- Find all macros, triggers, and views that reference it
- Update those objects after renaming the group
Understanding Complex Configuration
Scenario: You inherited a Zendesk instance with hundreds of triggers.
Problem: It's hard to understand how everything fits together.
Solution:
- View dependencies for key objects
- See which fields and groups are most commonly used
- Understand the "core" configuration vs. edge cases
Dependency Extraction Details
When Dependencies Are Extracted
Dependencies are extracted automatically after each sync:
- Configly fetches configuration from Zendesk
- Saves it as a snapshot
- Analyzes the snapshot to find dependencies
- Stores dependencies in the database for fast lookup
You don't need to do anything - dependency extraction happens in the background.
What Gets Analyzed
Configly scans the following parts of configuration objects:
| Object Type | Analysed Sections |
|---|---|
| Triggers | Conditions (all/any arrays), Actions, Webhook references, Routing Attribute references |
| Automations | Conditions (all/any arrays), Actions, Dynamic Content placeholder extraction ({{dc.X}}) |
| Macros | Actions, Restrictions (group/user) |
| Views | Conditions, Execution columns, Restrictions, Custom Status references |
| SLA Policies | Filter conditions, Brand references |
| Trigger Categories | Parent category to child Trigger relationships |
| Routing Attributes | Routing conditions and attribute references |
| Routing Attribute Values | Parent Routing Attribute relationships |
| Webhooks | Referenced by triggers and automations in actions |
| Targets | Referenced by triggers and automations in actions |
| Dynamic Content | Placeholder references in triggers, macros, and automations |
| App Installations | Relationships to Apps Owned |
| Articles | Parent Section and Category relationships |
| Custom Statuses | Referenced by views and triggers in conditions |
| Custom Objects | Custom Object Field relationships |
Field Reference Patterns
Configly recognises several patterns:
-
custom_fields_12345- Custom ticket field with ID 12345 -
group_id- Group reference in conditions or actions -
brand_id- Brand reference -
assignee_id/requester_id- User references -
current_tags- Tag references -
ticket_form_id- Ticket form reference -
webhook_id- Webhook reference in trigger/automation actions -
routing_attribute_id- Routing attribute reference -
custom_status_id- Custom status reference in view conditions -
{{dc.X}}- Dynamic content placeholder extraction
Dependency Statistics
From the dashboard, you can view dependency stats:
Total Dependencies: 1,247
- Ticket Fields: 523
- Groups: 198
- Tags: 412
- Brands: 45
- Users: 69
This gives you a sense of how interconnected your configuration is.
Most Referenced Objects
Configly also shows which fields and groups are most commonly used:
Top Referenced Ticket Fields:
1. "Priority Score" - used by 45 triggers
2. "Product Type" - used by 32 triggers
3. "Customer Tier" - used by 28 triggers
This helps you identify critical fields that many objects depend on.
Practical Examples
Example 1: Field Cleanup
Goal: Remove unused custom fields to simplify your Zendesk.
Workflow:
- View the list of ticket fields
- For each field, check reverse dependencies
- If a field has zero dependencies, it's safe to archive
- If a field has dependencies, review them to see if they're still needed
Example 2: Group Restructuring
Goal: Reorganize support teams and groups.
Workflow:
- Before changing groups, check dependencies
- Identify which macros, triggers, and views reference each group
- Plan to update those objects after restructuring
- Use the dependency list as a checklist during the change
Example 3: Macro Auditing
Goal: Ensure macros are restricted to the right teams.
Workflow:
- View macros and their restrictions
- Check which groups each macro is restricted to
- Verify the restrictions match your intended access control
- Update macros where restrictions are missing or incorrect
Example 4: Tag Standardization
Goal: Standardize tag names (e.g., rename vip to vip_customer).
Workflow:
- Find all triggers and automations that reference the
viptag - Note which objects need updating
- Rename the tag in Zendesk
- Update the dependent triggers and automations to use the new tag name
- Re-sync and verify dependencies updated
Limitations
External Dependencies
Configly only tracks dependencies within the configuration it syncs. It doesn't track:
- Zendesk apps or integrations that reference fields
- API clients that use custom fields
- Manual agent workflows that rely on specific tags
You'll need to check these separately.
Indirect Dependencies
Configly tracks direct references only. For example:
- Trigger A references Field X
- Trigger B copies the value from Field X to Field Y
Configly tracks that Trigger A uses Field X, but doesn't track that Trigger B indirectly uses Field X.
Dependency Accuracy
Configly extracts dependencies using a registry-driven pattern matcher that recognises references across all 42 object types — including ticket fields, user fields, organisation fields, groups, brands, tags, ticket forms, schedules, webhooks, routing attributes, custom statuses, trigger categories, dynamic content placeholders, app installations, and help centre content relationships.
The dependency engine supports bidirectional mapping, so you can query in either direction: "which triggers fire this webhook?" and "what does this trigger depend on?" both return results.
Broken References
When dependencies point to objects that no longer exist in Zendesk, they become "broken references". Configly's Broken Reference Detection automatically flags these as part of the Health Check engine.
Next Steps
- Broken Reference Detection - Find references to deleted objects
- Compare snapshots - See how dependencies changed between versions
- Sync configurations - Keep dependency data up to date
- Dashboard overview - View dependency statistics
Comments
0 comments
Please sign in to leave a comment.