Simplifying Complex Workflows with Custom Objects

With Custom Objects, customer data that doesn’t fit neatly within native Zendesk objects (organizations, users, tickets, etc.) can be stored in Zendesk to enhance your workflow. This is particularly useful for organizations that have multiple factors to account for within their support workflow. When things like job function, agent location, customer location, and evolving business processes all matter to the day-to-day operations, handling tickets with just Zendesk objects and business rules alone can get overly complicated.

Let’s follow an example of how to smooth those complexities out with custom objects:

Facilities Management Company (FMC) has customers that send service requests for their facilities to Zendesk Support agents to take action on. FMC serves large customers who have many facilities across different regions. So for the most efficient, customer-friendly workflow, teams of agents only focus on requests from specific regions that they’re assigned to cover. FMC is also growing fast. Flexibility must exist for teams’ coverage area assignments to shift based on need.

Challenges

At first glance, there are a few challenges with implementing a clean workflow for the agents within Support:

Agents only service requests for regions in their coverage area. It’s tempting to represent this coverage area assignment with an agent group. But there needs to be the flexibility to change the assignments, which could complicate group management for admins. It could also limit the ability to organize agents into groups based on job function (Maintenance, Janitorial Services, IT, etc.)

Customers also have individual facilities, each with unique details relevant to the service agent. For customers with dozens of facilities, it’s difficult to work with all of this info from a single organization profile. And they often have service locations across many regions.

To reduce complexity for teams, let’s add custom objects to the mix to create more meaningful relationships between key operational data, tickets and the groups of agents that support customers in them. This will help FMC’s workflow stay effective and scalable.

Modeling

There are a number of ways to try to structure data for this workflow. But for the custom data we add to Zendesk, let’s focus on only what is relevant to agents handling the requests. Agents need:

• Access to external data about the individual facility in the request
• The service coverage region the facility is in
• The service coverage regions they are assigned to

To represent the facility and region data that will be stored in Zendesk, we’ll set FMC up with two custom object types:

• Location for the facility location
• Region for the service coverage area

To tie these together, we’ll design a few one-to-many relationship types that describe how the location or region interacts with the other relevant objects in the workflow.

• The Location Region relationship represents the set of locations within a region.
• The Ticket Location relationship represents the possible service request tickets that may reference a location.
• The Coverage Group relationship represents the set of regions that an agent group supports.
• The Org Location relationship represents the set of locations that an organization has.

Implementation

Legacy Custom Objects

With Legacy Custom Objects, FMC will need to create the objects, relationships and records via API.

To start, add the object types. Location will have name (required), address, and notes properties. Region will have a required coverage area property.

Location:

{
  "data": {
    "key": "location",
    "schema": {
      "properties": {
        "name": {
          "type": "string",
          "description": "Facility Name"
        },
        "address": {
          "type": "string",
          "description": "Facility Address"
        },
        "notes": {
          "type": "sting",
          "description": "Key Property Notes"
        }
      },
      "required": ["name"]
    }
  }
}

Region:

{
  "data": {
    "key": "region",
    "schema": {
      "properties": {
        "coverage_area": {
          "type": "string",
          "description": "Coverage Region Name"
        }
      },
      "required": ["coverage_area"]
    }
  }
}

Next, add the set of one-to-many relationship types that will be used.

|  Source Object Type  |  Target Object Type  |
|----------------------|----------------------|
|  region              |  location            |
|  location            |  zen:ticket          |
|  zen:group           |  region              |
|  zen:organization    |  location            |

Once this is done, FMC can start creating location and region records from their property management system and coverage group records from their workforce management system.

New Custom Objects

We have an exciting New Custom Objects experience that simplifies creating the objects, relationships and records. With this new experience, FMC can build the objects and add records directly from Admin Center.

It also introduces Lookup relationship fields to simplify establishing relationships. With this powerful addition, FMC can create Org Location, Location Region, and Ticket Location lookup fields for easy relationship management between these objects that can be done from the agent interface.

Using an app to display the custom data to agents

To give the agents the ability to interact with this new data directly from a ticket, create a Support app. Depending on the specifics of the support flow for the customer, this app will give the agent the info they need to route the ticket in the sidebar. For example, if the customer submits requests with their building’s facility ID, we can store this ID on the location record when adding locations. Then the ticket sidebar app can fetch the location and related region/coverage groups.

There’s also flexibility to add other features as the workflow evolves — like using the organization to fetch all locations and give the agent the ability to manually select the ticket’s location. Or automatically selecting a group in the agent interface. This gives triaging agents the necessary context about the service request and the groups that are best suited for serving it.