ServiceNow Field Service Management: Security and Access Design

Access design for Field Service Management sets which roles can see and change each record, so technicians, dispatchers, supervisors and finance staff each have only what their job needs. This guide covers segregation of duties, mobile authentication, customer data limits, approval exceptions and the audit logs that record each access.

Role-Based Access and Segregation of Duties

Field Service Management requires clear role separation to prevent fraud and ensure accountability. Technicians who perform work should not approve their own timesheets or invoices. Schedulers who assign work should not modify completed work records. Supervisors who approve timesheets should not modify dispatch priorities. These separations must be enforced at the platform level, not left to manual control.

In a typical field operation, roles include: technician (performs work), dispatcher (assigns and re-prioritises work), supervisor (approves timesheets and quality checks), finance administrator (invoices and revenue recognition), and platform owner (configuration and user management). Each role has distinct access to tables, workflows, and reports. A technician sees only their own assignments and open service requests; a dispatcher sees the full queue and team resource availability; a supervisor sees performance across their team.

Mobile Device and Field Worker Authentication

Field technicians often work offline and return to the office intermittently to sync data. Mobile authentication must balance security with practical convenience. Passwords and two-factor authentication are standard; biometric authentication on field devices strengthens security without slowing adoption. Mobile applications should time out inactive sessions automatically to prevent another person from using an unattended device.

Service records created or modified on field devices must be cryptographically signed when synced back to the system. This creates an audit trail and prevents tampering during offline periods. If a technician’s device is lost or stolen, a remote-wipe capability is essential. Device management policies that enforce encryption, app restrictions, and regular patching reduce the risk of unauthorised data access in the field.

Customer Data and Personally Identifiable Information

Technicians access customer sites and customer systems during field work. They may see customer names, contact details, account numbers, and system configurations. Even if a technician never commits fraud, exposing this data to unauthorised parties violates customer privacy expectations and many data protection regulations. Access controls must limit what technicians see to data necessary for their current assignment. A technician repairing a printer should not see the customer’s financial details stored in the same service management system.

Audit logs must record every access to customer data and the business reason (specific service order, asset ticket, contract review). A quarterly audit comparing actual access to assigned work identifies outliers—data accessed that was not needed for assigned tasks. This signals possible policy violation or misuse.

Approval Workflows and Exception Handling

Timesheets, expense claims, and service report approvals are key control points. A technician submits time; a supervisor approves it within a defined timeframe. Late or missing approvals trigger an escalation to a manager. Approvers should have visibility into the work performed (work order details, travel time, parts used) to validate that claimed time and expenses correspond to actual work. Approvers who approve timesheets without reviewing details are not controlling the process.

Exceptions—work performed but not invoiced, extended jobs without prior approval, parts usage exceeding budget—should be flagged in the approval workflow for explicit sign-off. An exception that is merely logged but not approved is not an exception; it is an omission. Design your approval workflows to require explicit action on exceptions, not passive acceptance.

Audit Trails and Compliance Evidence

Field Service Management must log who created or modified each work record and when. This includes work orders, timesheets, service reports, and revenue postings. Logs should capture not just the change but the previous and new values, and the user who made the change. This level of detail is essential for regulatory audits, fraud investigations, and capacity planning. A technician might genuinely enter an unusually long week of hours; the audit trail helps you distinguish intentional time manipulation from data entry error.

Retention policies must preserve audit logs for at least the period required by your industry. Retention periods for each record type are set by the rules that apply to it, such as financial or HR record rules. Archive audit logs to an immutable storage system (a data lake, not an updatable database) to prevent tampering. If a dispute arises long after a service, the original audit trail must be available and unmodified.

Network and API Security for Integrations

Field Service Management systems integrate with accounting, customer relationship management, and parts management systems. Data flows between systems over networks that may include public internet, cellular connections, and corporate VPNs. All data in transit must be encrypted using TLS 1.2 or higher. All system-to-system APIs must authenticate using OAuth 2.0, mutual TLS, or an equivalent standard; shared passwords are not sufficient.

API rate limiting and request logging prevent a compromised system from extracting excessive data in bulk. If a parts system is breached and an attacker obtains a Field Service Management API key, rate limits and logging should detect and block high-volume extraction quickly. API tokens should expire regularly and be rotated as part of change management.

Review Cycle and Governance

Access controls and audit trails require ongoing review to remain effective. Review access on a regular cycle, validating that users still have the roles assigned to them (people change jobs; access is sometimes not revoked promptly). Periodically audit a sample of work orders and timesheets to confirm that approvals happened correctly and exceptions were handled appropriately. Review integration APIs regularly and ensure that encryption, rate limits, and token rotation policies are still current.

Mapping which data each field role is allowed to see and change

Field service security is mostly a question of data placement. A technician needs the customer’s site address, the equipment record and the job instructions. A finance administrator needs the rate card and the invoice lines. A supervisor needs the timesheets for their team. Very few roles need the whole record, but default configurations often grant it because it is the path of least resistance during build. The design task is to write down, table by table and field by field, which role needs each item and at which step of the job. Only then decide how the platform will enforce it. Access rules written from a job title tend to be too broad, because titles hide the actual screens people open. The access controls review approach shows how to test the rules against those screens.

Start with the data that causes the most damage if exposed: payment details, contract terms, personal contact information and any site access codes. Those fields deserve their own review, separate from the general role model, because a single ordinary-looking list view can show them to a person who has no reason to see them. For the related service, see access, privacy and segregation of duties.

Protecting offline data on field devices

Offline working creates a copy of the data on a device that can be lost, stolen or left in a van. The question is not whether to allow offline access, since most field operations need it, but how much is cached and for how long. Limit what is downloaded to the jobs assigned for the coming shift. Clear cached records when a job is closed or reassigned, and confirm that the device encrypts local storage. Ask the device management team to show you how a lost device is wiped and how long that takes once the device reconnects. If the answer is that it only happens when someone remembers, the control is not operating.

A review procedure for access rules

1. Pull the role list with its members, then check every name against the current staff register.
2. For each sensitive table, open it as a sample user from each role and confirm what appears in lists, forms and reports, not only what the role definition says.
3. Check that field-level restrictions also apply in mobile views and in exported reports, since these are the paths most often missed.
4. Test a reassignment: move a technician to a different territory, then confirm that the previous area’s customer data is no longer visible to them.
5. Record the findings, the owner of each fix, and the date the fix was verified.

Denied access that blocks real work

Over-restriction is the mirror image of the problem and causes its own damage. When a technician cannot see the parts list for a job, they may call a colleague for the information, forward it by a personal messaging app, or give up on the mobile app altogether. Each of those workarounds moves the data outside the controls. When a restriction causes a repeated complaint, treat the complaint as a design question. Find out which field the person needed, why they needed it at that step, and whether the answer is a narrower view rather than a broader role.

Logging the access that matters

Audit logs for field work should record reads of the most sensitive fields as well as changes, because a technician who opens a customer’s financial record without a job reason is a different event from one who edits a timesheet. Keep the log in a store that the platform users cannot edit. Review a sample of reads each quarter against assigned work, and look most closely at people who open records outside their territory.

Common review findings and how to close them

Many field service reviews find the same few gaps: a reporting role that inherits write access from a broader group, a contractor account that outlives its contract, a mobile form that shows a field hidden on desktop, and an integration user with administrator rights because nobody wanted the sync to fail. Each one has a simple fix, but the fix is easier to make when it is assigned to a named owner with a due date. Keep the findings in the same log as the access review so that repeat findings are visible and can be escalated. Audit trail evidence is a related read for reviews like this.

Should technicians be able to edit their own timesheets?

They can enter time, but the approval step should belong to someone else. Where the technician can edit after submission, the edit should be recorded with the previous value so that a supervisor can see what changed before approving.

How do we handle a contractor who needs access for a short project?

Create the account with an end date that matches the contract, assign the narrowest role that supports the work, and set a reminder for the owner to review it before that date. Contractor accounts with no end date often appear among the findings reviewers raise.

Is a separate security review needed for each new integration?

Yes, because each integration adds a credential and a data path. Review the integration user’s rights, the token lifetime and the rotation process as part of the change, not as a later audit item.