Region-Based Ticket Routing in Telecom Operations: A Practical Guide to Using the Circle Field in Clappia

In the telecom industry, network operations are organised geographically. Circles, which refer to licensed geographic operating zones such as state or regional boundaries, are the primary unit of operational responsibility. A fault at a site in one circle belongs to that circle's NOC (Network Operations Centre) team, not to a central team managing all circles from a single queue. When a ticket is created for a site in the North circle, the North team needs to know. When it is in the South circle, the South team does. Routing that sounds simple in principle becomes a genuine operational problem at scale when it is done manually.

The failure mode of manual routing is well-known to anyone who has managed a multi-circle NOC. A new ticket lands in the central inbox. Someone reads it, identifies the circle from the site details, and forwards it to the right regional mailbox. During peak hours or night shifts, that forwarding step gets missed. Tickets sit in the central inbox while the regional team that should be acting on them waits for an alert that never arrives. By the time the routing error is noticed, the ticket has aged past its ETR commitment.

Automated circle-based routing removes that forwarding step entirely. The moment a ticket is created, the workflow reads the Circle field, identifies the regional branch that matches, and sends the email directly to that region's operations inbox without any human intervention. This guide covers exactly how to build that routing in Clappia, including how to structure the workflow branches, why the condition ordering matters, how to handle circles that are not yet configured, and how to connect routing to automatic status progression.

Why the Circle Field Is the Right Routing Key

The Circle field in the ticketing form is auto-populated from the Site Master Data app when a site is selected. Because it comes from master data rather than free-text input, it is always one of a finite set of known values. There is no risk of one engineer typing 'North' and another typing 'North Region' for the same circle, because the field is pulled automatically, not typed manually.

This consistency is what makes the Circle field reliable as a routing key. Workflow condition branches check for exact string matches. A branch configured to fire when Circle equals 'North' will only fire when the field contains exactly that value. If the field came from free-text input, you would spend significant time managing variations and typos. Because it comes from master data, the value is always clean and the routing is always predictable.

Routing logic is only as reliable as the data it routes on. A field that is auto-populated from a controlled master list is fundamentally more trustworthy than one that depends on consistent human input.

The Site Master Data app stores one record per site, and each record carries the Circle as part of the site's geographic attributes alongside State, District, and Sub-District. When a field engineer or NOC analyst selects a site in the ticketing form, the Circle value loads automatically into the form as a read-only field. By the time the ticket is saved, the Circle is already there, correct, and ready to be evaluated by the routing workflow.

Understanding the Routing Branch Architecture

Before building anything, it helps to see the full routing architecture as a structure. The on-save workflow for the ticketing app has several parallel branches running simultaneously when a ticket is created. The routing branches are separate from the initial notification branches and operate independently.

Each circle gets its own branch. Every branch follows the same three-step pattern:

1. Status check: Confirm the ticket status equals 'Ticket Created'. This prevents the routing from firing again if the ticket is later edited and saved.
2. Short wait: Pause for a brief period, typically 30 to 60 seconds. This gives the initial notifications time to fire first and ensures the routing email does not arrive before the recipient has any context about the ticket.
3. Circle check and email: Confirm the Circle field equals the specific value for this branch, then send an email to that circle's operations mailbox.

Each branch runs in parallel with the others. When a ticket is saved, all branches evaluate their first condition simultaneously. Only the branch whose Circle condition matches will proceed to send an email. The others will reach the Circle check, find that it does not match, and stop there.

Building the Routing Workflow in Clappia

Step 1: Open the On-Save Workflow

In your Corrective Maintenance Ticketing app, go to Design App and then Workflows. Find the New Submission Flow, which is the on-save trigger that fires every time a ticket is created. This is where all routing branches live alongside the initial notification actions.

Step 2: Add the First Routing Branch

Click to add a new parallel branch in the workflow. This branch will handle your first circle. Add a Condition block as the first step in the branch and set it to check:

{Status} = "Ticket Created"

Under the matching path of this condition, add a Wait node. Set the duration to 30 or 60 seconds. This wait is important: without it, the routing email fires at exactly the same moment as the initial Telegram and email notifications, and recipients receive a flood of messages simultaneously. The short wait staggers the delivery without meaningfully delaying the regional team's awareness.

After the Wait node, add a second Condition block:

{Circle} = "North"

Under the matching path of this second condition, add an Email action. Set the recipient to the North circle's operations mailbox. In the email subject, include the ticket reference number and site name so the recipient can identify the ticket immediately. In the body, include the key operational details: Site ID, Circle, District, Fault Start Date and Time, Alarm type, Fault Category, ETR, and a direct link to the submission. The Circle field itself, the Site Name, and the District are all auto-populated from master data, so they are available as field variables using the @ syntax in the email template. Type @ in the email body field and select from the list of available fields.

Step 3: Duplicate the Branch for Each Additional Circle

Once the first branch is working correctly, create identical branches for each additional circle in your network. Each branch is a copy of the first with two changes: the Circle condition value and the recipient email address. If you operate ten circles, you will have ten routing branches. This sounds like a lot, but each branch is structurally identical and adding a new one takes under two minutes once you have the pattern established.

Keep the branch names descriptive in the workflow editor. Naming them 'Routing: North', 'Routing: South', and so on makes the workflow diagram readable and makes it immediately obvious when a circle is missing from the routing configuration.

Step 4: Handle the Status Check Correctly

The first condition in every routing branch checks that Status equals 'Ticket Created'. This is not redundant with the fact that the workflow is triggered on save. Tickets can be saved multiple times: when first created, when updated by the engineer, when the status changes. Without the status check, a routing email would fire every time the ticket is saved, potentially sending the same email to the regional inbox dozens of times over the ticket's lifetime.

The status check is what limits the routing to the moment of ticket creation. It is the most important condition in the branch, and it must be the first check, before the wait and before the Circle check. If you put the Circle check first and the status check second, the branch will still fire at the right time, but you will have evaluated the Circle unnecessarily on every save before hitting the status gate. Put the status check first as a matter of discipline and efficiency.

Step 5: Test Each Branch Before Going Live

Testing region routing is straightforward but must be done for each circle individually. Create a test ticket with the Circle set to each value in turn and verify that the correct regional mailbox receives the email. Check:

• The email arrives within 60 to 90 seconds of ticket creation (accounting for the wait node)
• The subject line contains the correct ticket reference number
• The body contains the correct site name, circle, district, and fault details
• No other regional mailbox receives the email
• The email does not re-fire when the ticket is subsequently edited

If an email is not arriving for a specific circle, the most likely causes are: the Circle value in the test ticket does not exactly match the string in the workflow condition (check for trailing spaces or capitalisation differences), the Wait node duration is longer than expected, or the status check is blocking the branch because the test ticket was created with a different initial status.

What Happens When No Branch Matches

This is the failure mode that is easy to overlook. If a ticket is created for a site whose Circle value does not match any routing branch, the ticket is not routed to any regional inbox. It exists in the system, the central NOC may have received the initial notification, but the regional team that is supposed to action it never finds out.

This happens most commonly in three scenarios:

• A new circle is added to the network: Sites in the new circle submit tickets but no routing branch exists yet for it.
• A circle is renamed in the Site Master Data app: The workflow branch still checks for the old name, but the field now contains the new name. Every ticket from sites in that circle silently fails to route.
• A data entry error in the Site Master: A site record has an incorrect or misspelled Circle value. Tickets for that site do not match any branch.

The practical mitigation for all three is a catch-all monitoring process. Once a month, filter your ticketing app submissions to show tickets where Status stayed at 'Ticket Created' longer than your standard ETR window. Any ticket that was never actioned is a candidate for a routing failure. Cross-reference the Circle values in those tickets against your list of configured routing branches to identify gaps.

If you want a more active safeguard, add a final catch-all branch to your workflow that fires when Status equals 'Ticket Created' and none of the specific Circle conditions have been met. This branch can send an alert to the central NOC admin mailbox flagging that a ticket has been created for an unrecognised circle. It requires a bit more workflow logic to implement cleanly, but it converts a silent failure into a visible one.

Connecting Circle Routing to Automatic Status Progression

Circle routing and auto-assignment are two separate workflow branches but they work as a pair. While the routing branches are delivering the regional email, a parallel auto-assignment branch handles the status update.

The auto-assignment branch follows a simpler pattern: check Status equals 'Ticket Created', wait 60 seconds, then use an Edit Submission action to update the Status field to 'Ticket Assigned'. This runs regardless of which circle the ticket belongs to, because assignment is a system-level action that applies to all tickets uniformly.

The sequence from the perspective of a regional team member looks like this:

1. Ticket is created. Initial Telegram notifications go to the engineer, cluster lead (area supervisor), and NOC leads immediately.
2. After 30 to 60 seconds, the routing email arrives in the regional operations inbox with full ticket details.
3. After 60 seconds (running in parallel), the ticket status updates to 'Ticket Assigned' automatically.
4. The regional team opens the ticket, already assigned, with all site context pre-loaded, and begins actioning it.

The short gap between the routing email and the status update means the regional team receives the notification while the ticket is still in 'Ticket Created' state. By the time they click the link to open it, the status has already progressed to 'Assigned'. This is the intended behaviour, not a timing problem. The routing email informs; the status update records that the handoff has been made.

Maintaining Circle Routing as Your Network Grows

A routing configuration that works perfectly at launch will drift over time if it is not actively maintained. The Circle field values in your Site Master Data app are the ground truth; the workflow branch conditions must always reflect them exactly. Here is a simple maintenance checklist to run whenever your network structure changes:

The most dangerous change is a circle rename, because it breaks routing silently. If the Site Master is updated but the workflow is not, tickets from affected sites will stop routing without any error message. Build a habit of updating the workflow on the same day as any Site Master structural change, and test at least one ticket from the affected circle before considering the change complete.

Combining Circle Routing with On-Platform Ticket Owners

The regional email routing described in this guide handles external notification: getting the right email to the right inbox. Clappia also supports assigning submission owners within the platform, which controls who sees tickets in their personal queue and who receives in-platform notifications.

For a complete assignment model, use both together. The Circle routing email notifies the regional team externally. The submission owner assignment gives the specific engineer or supervisor in-platform ownership of the ticket. These two mechanisms serve different purposes and different channels, and they complement each other well.

In practice, the auto-assignment workflow branch that updates the status to 'Ticket Assigned' can also set the submission owner at the same time, if your Clappia plan supports owner assignment via workflow. The engineer or cluster lead (area supervisor) pulled from the Site Master Data app at ticket creation time is the natural candidate for initial ownership, since they are already associated with the site in your master data.

Access, Permissions, and Mobile Use

From a permissions perspective, circle routing is entirely server-side. Field engineers submitting tickets from the Clappia mobile app on Android or iOS do not need any special permissions for the routing to work. The workflow fires based on the ticket data, not the permissions of the person who created it.

• Field engineers and NOC analysts: Standard create and update access. They do not see or interact with the routing workflow.
• Regional supervisors: Should have view access to all submissions within their circle so they can monitor the regional ticket queue. Filtered views by Circle value give them a clean list without seeing tickets from other regions.
• Workflow administrators: Full access to modify and test the routing branches. Only administrators should be adjusting Circle condition strings or changing regional mailbox recipients.

One practical note for offline submissions: when a field engineer creates a ticket in offline mode and it syncs when connectivity is restored, the on-save workflow fires at sync time. The routing email will go to the correct regional inbox at that point, with the same delay from the Wait node. There is no difference in routing behaviour between online and offline submissions once the sync happens.

Conclusion

Region-based ticket routing is one of those workflow features that seems straightforward until you think carefully about the condition ordering, the silent failure modes, and the maintenance burden as the network grows. Getting it right from the start, with the status check first, a short wait before the Circle check, and a clear naming convention for branches, means the routing runs reliably without anyone having to think about it on a day-to-day basis.

The Circle field is the right routing key because it comes from master data rather than manual input, making it consistent and match-safe for workflow conditions. Combined with the auto-assignment status update, the routing creates a clean handoff sequence: the ticket is created, the regional team is notified, and the status progresses to Assigned, all within 60 to 90 seconds and all without any manual forwarding or coordination.

The maintenance discipline is what keeps it working over time. Treat every change to circle names or regional team structures as a workflow change event, not just a data change event. The two minutes it takes to update a routing branch condition is a much smaller cost than the tickets that slip through silently when the configuration drifts out of sync with the operational reality it is meant to reflect.