.jpg)
When a site goes down or a fault is reported, the clock starts immediately. For any operations team managing a distributed network of sites, whether in telecoms, utilities, facilities, or field services, the first few minutes after a fault is logged are critical. Who gets notified? Does the right engineer know? Has a ticket been assigned? In most manual setups, the answers to those questions depend on someone remembering to send a message, forward an email, or update a spreadsheet. That lag is exactly where response times slip.
This guide walks through how to build a complete fault ticketing system in Clappia that removes that lag entirely. When a ticket is created, Telegram alerts fire automatically to every relevant role, an email goes to the central operations team, region-specific inboxes receive their own notification, and the ticket status updates to 'Assigned' within seconds, all without anyone manually triggering any of it.
The system is built across two Clappia apps: a Site Master Data app that stores your site records and contact details, and a Corrective Maintenance Ticketing app where tickets are created, classified, tracked, and closed. Everything in the ticketing app pulls from the master data, so field teams never type contact details manually and notifications always reach the right people.
Most dedicated ticketing tools are built for IT helpdesk scenarios: a user raises a ticket, an agent picks it up, it gets resolved. Field operations ticketing is a different problem. You need GPS-aware forms that work on mobile in poor connectivity, photo uploads for evidence, cascaded fault classification that guides the user through diagnosis, and multi-channel notifications that reach people on Telegram and email simultaneously, not just within a web portal.
Clappia handles all of that without custom development. The form builder, workflow engine, and mobile app cover the field operations use case well, and the Telegram notification workflow is a native feature. The result is a system your NOC team can operate from a browser and your field engineers can use from their phones, with or without a reliable internet connection.
The fastest way to reduce mean time to repair is to eliminate the gap between fault detection and the right person knowing about it. Automated notifications close that gap at the moment of ticket creation.
Before jumping into the build steps, here is what the two apps do and how they connect:
| App | Purpose | Has Workflows? |
|---|---|---|
| Site Master Data | Stores site identifiers, location, and role-based contact details for every site | No |
| Corrective Maintenance Ticketing | Creates and manages fault tickets, pulls site and contact data from the master, triggers all notifications and auto-assignment | Yes |
The Site Master Data app is the foundation. You populate it once and keep it updated. The ticketing app reads from it every time a new ticket is created, so the notifications always use current contact details without anyone needing to update the ticketing form itself.
Step 1: Build the Site Master Data App
Log in to your Clappia workspace. On the home screen, click the '+ New App' button. In Design App, name the app 'Site Master Data'. This app has no workflows and no complex logic. It is a structured reference database that your ticketing app will pull from.
Inside the app builder, click ‘Add Section’ and name it like “Site Identification Fields”, then click '+ Add Field' to add the blocks. All fields in this app should be visible at all times with no display conditions (unless you don’t need them to be). You can add multiple sections in an app.
Add the following:
Site Identification Fields
Add a Single Line Text block for each of the following:
If your sites carry multiple identifier codes, for example one code per frequency band or network type, add a separate Single Line Text block for each. Label them clearly so the ticketing app can map them correctly when it pulls the data.
Role-Based Contact Fields
This is the section that powers your automatic notifications. For each operational role, add a group of Single Line Text blocks covering Name, Phone Number, Email ID, and Telegram Chat ID. The roles to cover are:
The Telegram Chat ID field is important. This is the unique identifier Clappia uses when sending Telegram messages through its notification workflow. Each person's Chat ID is different from their phone number or username, and it needs to be stored here so the workflow can reference it at the time a ticket is created.
Once the app is built, add a record for every site your team manages. These records are what the ticketing app will search and pull from. Keep this app updated whenever a contact changes roles or leaves the team, and your ticketing notifications will always be accurate.
Step 2: Create the Corrective Maintenance Ticketing App
Go back to the Clappia home screen and click '+ New App' again. Name this app 'Corrective Maintenance Ticketing'. This is the app your NOC team and field engineers will use every time a fault is detected. It has two main sections: Ticket Assignment (where site context is loaded and the fault is classified) and Details (where fault timing, impact, and escalation information is captured). Closure fields are added later.
Click 'Add Section' in the builder to create named sections. Fields inside a section can share display conditions, which becomes useful for the hub site impact fields covered later.
Ticket Identification
At the top of the form, add a Single Selector block labelled 'Ticket Type'. Add options such as 'Proactive Ticket' and 'Reactive Ticket' depending on how your team classifies incoming faults.
Add a Unique Sequential block labelled 'Ticket Number' (or TT Number). Set a prefix such as 'TT-' so each ticket gets a traceable identifier like TT-00142. Make sure this field has no display condition attached to it, or set the condition to one that is always true, otherwise it will remain hidden and the sequential number will not generate. This is a common configuration error worth checking before going live.
Section: Ticket Assignment
This section is where the site is selected and all contact and location details are pulled in automatically. Add the following:
Circle / Region picker: Add a Get Data from Other Apps block, which lets your form pull information from another app in your Clappia workspace. Point this block at your Site Master Data app. When a user selects a circle or region, this block loads the relevant site records for the next field.
Site ID picker: Add a second Get Data from Other Apps block, also pointing at Site Master Data, filtered by the circle selected above. When the user picks a Site ID, this block auto-populates the following fields as read-only:
These pulled fields should be set to read-only so users cannot accidentally overwrite master data. The field team only makes two selections; every other field fills itself.
Fault Classification Fields
Still inside the Ticket Assignment section, add the fields that classify the fault:
Ticket Aging Formula
Add a Date/Time block labelled 'Submission Created Time'. This field captures the exact moment the ticket form is opened and acts as the aging anchor. Then add a Formula block labelled 'Ticket Age'. To insert field variables in the formula editor, type @ and select the field name from the list that appears. Clappia wraps it in curly brackets automatically.
The formula to calculate how long a ticket has been open since it was created:
TEXT(INT((NOW()-{Submission Created Time})*24),"0") & " Hrs " & TEXT(INT(MOD((NOW()-{Submission Created Time})*24*60,60)),"0") & " Min"
Fields used: Submission Created Time.
What the formula does: Calculates the difference between the current time and the submission creation time, then formats it as hours and minutes.
What the user sees: A read-only field showing something like '3 Hrs 42 Min', updated each time the form is opened. This gives the NOC team an at-a-glance view of how long a ticket has been active without any manual calculation.
Step 3: Add the Fault Details Section
Click 'Add Section' and name it 'Details'. This section captures the timing and impact of the fault.
Fault Timing
Hub Site Impact
In network operations, a hub site failure can cascade to affect multiple downstream or child sites. Add the following fields to capture this:
These two conditional fields ensure the form stays clean for regular single-site faults while capturing the extra detail needed for hub-level outages. The hub site name and child site count are also included in the Telegram notification message so recipients immediately understand the blast radius of the fault.
Step 4: Add the Outage Classification Cascade
A fault classification cascade is a series of dropdown fields where each selection narrows the options in the next field. This guides the user through root-cause analysis systematically rather than relying on free-text descriptions that are impossible to aggregate in reports.
Add a new section called 'Fault Description' and build the cascade as follows:
In Clappia, you implement this cascade using display conditions on each field. Each level's options are shown or hidden based on the selection made in the level above. Build this incrementally, adding one level at a time and testing the conditions before moving to the next.
Also add a Single Selector block labelled 'Fault Nature' with options such as Operational, Theft, and Damage. This distinguishes the type of incident regardless of where it sits in the taxonomy.
Step 5: Add Closure Fields and Photo Evidence
Add a final section called 'General Information' for closure documentation. These fields are filled in when the fault is resolved:
Total Repair Time Formula
Add a Formula block labelled 'Total Time Spent on Fault Rectification (Hours)'. This calculates the difference between the fault start and fault close timestamps:
(({Fault Close Date}-{Fault Start Date})*24)+(({Fault Close Time}-{Fault Start Time})*24)
Fields used: Fault Close Date, Fault Start Date, Fault Close Time, Fault Start Time.
What the formula does: Subtracts the start date and time from the close date and time, converting the result to hours.
What the user sees: A read-only numeric value such as '4.5', representing the total hours taken to resolve the fault. This feeds directly into SLA reporting and mean time to repair calculations.
Photo Evidence
Add two File Upload blocks inside this section:
Before and after photos create an auditable evidence trail for each fault. Enable watermarking on these upload fields if your Clappia plan supports it, so each photo is automatically stamped with the submission ID, timestamp, and GPS location.
Step 6: Add a Spare Consumption Section
For field operations, tracking what was used to fix a fault is as important as logging the fault itself. Add a section called 'Spare Consumption Report' with:
This section feeds your spare parts consumption reports and helps operations managers track inventory movement alongside fault resolution.
Step 7: Configure the Notification and Auto-Assignment Workflows
This is where the system becomes genuinely powerful. Open Design App > Workflows in the Corrective Maintenance Ticketing app. The main workflow runs on save, meaning it fires every time a submission is created.
On Save: Telegram Alerts to Role-Based Contacts
Inside the New Submission Flow, add a Condition block that checks whether the Status field equals 'Ticket Created'. Under the matching branch, add a Telegram notification action for each of the following roles:
For each Telegram action, set the recipient to the corresponding Telegram Chat ID field that was auto-populated from the Site Master Data app. The message body should include the key details a recipient needs to act immediately. A typical message looks like this:
New Fault Ticket: {Ticket Number}
Site: {Site Name} | {Site ID}
Circle: {Circle}
District: {District}
Alarm: {Alarm Reported}
Fault Type: {Fault Type} | Category: {Fault Category}
Fault Start: {Fault Start Date} {Fault Start Time}
ETR: {Estimated Time of Resolution}
Hub Site Down: {Hub Site Down} | Child Sites: {Number of Affected Child Sites}
If the hub site fields are blank (because Hub Site Down = Not Applicable), you can wrap them in an IF condition in the message template so they only appear when relevant.
On Save: Email to Central Operations Team
After the Telegram actions, add an Email workflow action. Send this to your central NOC or operations team mailbox. The email subject and body can mirror the Telegram message content but with more formatting room. Include a direct link to the submission so the recipient can open the ticket with one click.
On Save: Region-Based Email Routing
Different regions or circles often have their own operations inbox. To route emails correctly, add a separate condition branch for each region. Each branch checks two things: Status = 'Ticket Created' AND Circle = the specific region name. When both conditions match, an email is sent to that region's inbox.
Add one branch per region you operate. If you have ten regions, you will have ten branches. This sounds like a lot, but each branch is identical in structure, just with a different Circle value and a different email address. Once you have built one, duplicating it and changing the values takes under a minute per region.
Region routing ensures that a fault in one area is not buried in a central inbox where the relevant local team might miss it. Each team only sees the tickets that are theirs to action.
On Save: Auto-Assignment After a Short Wait
The final workflow branch handles auto-assignment. Add a parallel branch (running alongside the notification branches) that:
This simulates an assignment acknowledgement step without requiring a human to manually update the status. The ticket moves from 'Created' to 'Assigned' automatically, so your dashboard never shows a backlog of unacknowledged tickets. If your team needs a human to confirm assignment before the status changes, you can extend the wait duration or replace the wait with an approval step.
Step 8: Define the Ticket Status Lifecycle
The status field drives the workflow logic and gives the NOC team a clear view of where each ticket stands. Set it up as a Single Selector block with the following stages:
| Status | Meaning | Who Sets It |
|---|---|---|
| Ticket Created | Fault reported and logged | Auto-set on submission |
| Ticket Assigned | Assigned to a team or engineer | Auto-set by workflow after 60 seconds |
| Accepted | Engineer has acknowledged and accepted the ticket | Field engineer |
| Active | Work in progress | Field engineer or NOC |
| Restored | Service restored, pending closure documentation | Field engineer |
| Ticket Closed | Fully documented and closed | NOC or supervisor |
Once a ticket reaches 'Ticket Closed', block further edits by adding a validation rule that prevents submission when Status = 'Ticket Closed'. This preserves the integrity of closed ticket records and prevents accidental reopening.
Step 9: Configure Access, Permissions, and Mobile Use
In Clappia, you manage who can access each app from the 'Manage Users' section within the app settings. For this system:
The Clappia mobile app is available on Android and iOS and is where most field engineers will interact with the ticketing app. For sites with poor connectivity, Clappia's offline mode allows engineers to create and fill tickets without a signal. The submission syncs automatically when the device reconnects, and the workflow notifications fire at that point.
This is particularly useful in remote infrastructure operations where connectivity at the fault site itself is often the very thing that is broken.
Step 10: Test Before Going Live
Before handing the system to your team, run through the following checks:
Quick Reference: Fields and Their Block Types
| Field | Block Type | Section |
|---|---|---|
| Ticket Type | Single Selector | Header |
| Ticket Number | Unique Sequential | Header |
| Circle / Region | Get Data from Other Apps | Ticket Assignment |
| Site ID | Get Data from Other Apps | Ticket Assignment |
| Site Name, Organisation, District, etc. | Single Line Text (read-only, pulled) | Ticket Assignment |
| All Contact Fields (Name, Phone, Chat ID) | Single Line Text (read-only, pulled) | Ticket Assignment |
| Alarm Reported | Single Selector | Ticket Assignment |
| Fault Type | Single Selector | Ticket Assignment |
| Fault Category | Single Selector | Ticket Assignment |
| Submission Created Time | Date/Time | Ticket Assignment |
| Ticket Age | Formula | Ticket Assignment |
| Fault Start Date | Date | Details |
| Fault Start Time | Time | Details |
| Estimated Time of Resolution | Single Selector | Details |
| Hub Site Down | Single Selector | Details |
| Number of Affected Child Sites | Single Selector (conditional) | Details |
| Hub Site Name | Single Line Text (conditional) | Details |
| Fault Category / Sub-Category cascade | Single Selector (cascaded) | Fault Description |
| Fault Nature | Single Selector | Fault Description |
| Spare Details | Long Text | Spare Consumption |
| Status of Faulty Hardware | Single Selector | Spare Consumption |
| Fault Close Date and Time | Date / Time | General Information |
| RFO, RCA, Action Taken | Long Text | General Information |
| Fault Rectified By | Single Line Text | General Information |
| Total Time on Rectification (Hours) | Formula | General Information |
| Photo of Faulty Equipment | File Upload (camera) | General Information |
| Photo After Rectification | File Upload (camera) | General Information |
Conclusion
A fault ticketing system that only logs the problem is not enough. For distributed field operations, the value is in what happens the moment the ticket is saved: the right people are notified instantly, across the right channels, the ticket is automatically assigned, and the operations team has a real-time view of every open fault without chasing anyone for an update.
The system described in this guide gives you all of that in two Clappia apps. The Site Master Data app means your contact details are always current and accurate, because notifications pull from the master, not from whatever a field engineer typed into a form. The workflow engine handles Telegram alerts, email routing, and auto-assignment without any manual steps. And the fault classification cascade, combined with closure fields and photo evidence, means every closed ticket is a complete, auditable record.
Start with the Site Master Data app and populate it with a handful of test sites. Then build the ticketing app section by section, testing the workflows as you go rather than all at once. Once the core notification loop is working, add the cascade, the spare consumption section, and the closure fields. The system can go live incrementally and be extended as your team gets comfortable with it.
L374, 1st Floor, 5th Main Rd, Sector 6, HSR Layout, Bengaluru, Karnataka 560102, India
3500 S DuPont Hwy, Dover,
Kent 19901, Delaware, USA
.svg){kind=small}
3500 S DuPont Hwy, Dover,
Kent 19901, Delaware, USA
L374, 1st Floor, 5th Main Rd, Sector 6, HSR Layout, Bengaluru, Karnataka 560102, India
%20(1).jpg)
.avif)
