Field Engineer Mobile App: What Contractors Need

A field engineer mobile app lets a contractor’s site engineers and supervisors receive survey, permit, execution and maintenance tasks, record stage data and photos on site, and move the work order on without returning to the office. Its value lies not in the small screen but in enforcing the main system’s rules: permissions, district scope, mandatory fields and time limits.

Below are the buying criteria that matter before you roll an app out to field crews, followed by what ELX provides — and what it does not promise.

What should a field engineer mobile app do?

Site engineers move between jobs all day, and nearly every request they get concerns one work order: a survey, a permit follow-up, an execution update, a set of photos. When that work lives in chats and calls, it reaches the office late and incomplete, and someone re-keys it.

Saudi Arabia’s digital environment is ready for this way of working. The UN E-Government Survey 2024 reports a 99% internet penetration rate and 98% of government services available online, and places the Kingdom among Asia’s leaders in the highest (“VH”) e-government rating class. Signal strength still varies between excavation sites, so ask how the app behaves on a weak connection.

Which stages can be carried out from the site?

Not every stage is field work. Registering the order and preparing the extract are mostly office tasks, while the survey, execution and maintenance happen on site, and engineers may need to update permit details while out in the field. Our guide to utility work order stages covers the full sequence. Here is what the ELX field API supports per stage:

On four of these stages, engineers can close the full cycle on site: claim, record, attach, relay. Connections and maintenance orders are saved with their files from the field and relayed in the web system — see the guide to maintenance and emergency orders.

How do you keep the same validation rules on mobile and web?

The biggest risk with a stand-alone field app is a back door: an order relayed from a phone without a mandatory attachment, or a required delay justification quietly skipped. Insist that whatever the web system rejects, the app rejects too — which means the app must run through the system’s own logic, not a parallel database synced later. Ask three questions:

1. Mandatory data: does relaying from mobile check the fields, notes and attachments set as mandatory for that stage?
2. Time limits: does the app demand a delay justification once the order is past its limit and justification is mandatory?
3. Lookups: do drill types, implementation items, materials and warehouses come from the system’s guides, or from free text?

In ELX, the API relays survey, permit, project and replay tasks under the same validation rules as the web system, and pulls its lookups from the system’s guides: drill types, permit-need options, material categories, implementation items, warehouses, work types and disbursement statuses. For how limits and justifications work, read the guide to stage time limits and delay justifications.

Why should mobile screens follow user permissions?

A field engineer needs neither every screen nor every work order. A survey team in one district has no need to see a project across town, and supervisors need screens technicians do not. Define mobile rights separately from web rights and the two soon drift apart.

Build the app’s menu from the permission matrix the administrator already manages, and scope data to the user’s districts. In ELX, permissions work on three levels:

• Action-level rights: show, add, update, delete, relay and show others’ data, set per screen.
• Geographic scope: users are linked to their branches, cities and districts, and their lists and dashboard in the web system stay inside that scope.
• Order ownership: only the assigned user can open a work order, unless they hold “Show other users’ data”.

The mobile menu is built from that same matrix: at sign-in, the app fetches the mobile screens the user may open and the districts assigned to them. For more on designing roles and rights, see the guide to permissions and the audit trail.

How are photos, files and delay justifications uploaded from site?

A photo left on an engineer’s phone proves nothing to the office or the quality inspector; it must land on the work order and the stage it belongs to, where whoever handles the order next can see it. Here is a field day in ELX when the app is built on its API:

1. Alert and assignment

   When an order enters a stage, ELX sends an alert via Telegram and, when enabled, WhatsApp to users who can view that stage’s screen and have notifications on. A dispatcher then assigns the order from the distribution basket, or the engineer claims it directly.

2. Sign in and confirm

   The engineer signs in with username and password, opens their task list and confirms receipt of the assigned task.

3. Record the data

   Stage fields are filled in from the lookup lists, with the task’s files at hand.

4. Upload photos and files

   Site photos and documents go to the same stage, ideally with names that describe them.

5. Justify a delay if needed

   If the order is past its limit and justification is mandatory, the engineer adds a reason with supporting files, and can remove a file attached by mistake.

6. Save or relay

   Save if work remains, or — for survey, permit, project and replay tasks — relay once the system has checked the mandatory fields, notes and attachments.

In the web system, files from every stage come together on one attachments screen per work order and download as a single ZIP named after the order, so nobody has to hunt for a survey photo on a colleague’s phone.

How do you track team locations while respecting privacy?

Knowing where a crew was last seen helps a supervisor send the nearest team to an urgent notice. But the dot on the map carries an engineer’s name and traces their day.

Saudi Arabia’s Personal Data Protection Law (PDPL), approved by Royal Decree No. M/19 dated 9/2/1443H, came into force on 14 September 2023, and its one-year grace period ended on 14 September 2024. The Saudi Data and AI Authority (SDAIA) is the competent authority. SDAIA’s guide cites names, ID numbers, contact details and images as examples of personal data. Because a location tied to a named engineer points to an identifiable person, the prudent course is to treat it as personal data.

The law also gives individuals rights: to be informed of the legal basis and purpose of collection, to access their data and obtain a copy in a clear, readable format, to have it corrected or updated, to request its destruction and to withdraw consent. Practices that help a contractor respect these rights when tracking locations include:

• Tell engineers in writing that the app sends their location, why, and who can see it.
• Collect only what the purpose needs — a last known location during work, not a detailed movement history.
• Limit access to location data to the supervisors who need it.
• Set a retention period, and name who answers staff requests about their data.

In ELX, the API accepts GPS points from the field app; the system keeps up to the 10 most recent points per upload and updates the user’s last known location. Matrix can show these locations on a central monitoring map, and if your supervisors need to see them, raise it with the Matrix team. Notice, access and retention rules remain your company’s decision.

Checklist for choosing a field app

Confirm these points with the vendor, ideally in a demo on one of your own work orders:

• Mobile screens come from the same user permissions as the web system.
• Tasks stay within the branches and districts assigned to the user.
• Relaying from mobile enforces the same mandatory fields, notes and attachments.
• Overdue orders require a justification with files when settings make it mandatory.
• Photos and files go straight to the work order and its stage.
• Lookup lists come from the system’s guides, not free text.
• The interface works in Arabic (right-to-left) and English.
• Location tracking has a written policy covering notice, access and retention.
• The vendor has answered in writing on app-store availability, weak-signal behaviour and how alerts reach field staff.

How does ELX support field work?

ELX is a bilingual (Arabic/English) cloud (SaaS) service, hosted and operated by Matrix, that runs in the browser with no servers needed on the contractor’s side. It is built for electricity-network contractors in Saudi Arabia to carry each work order from registration to archive. For field work it provides a mobile-ready API for field apps: a separate, documented REST API built for a field mobile app to run on.

Sign-in, permissions and language

Signing in with username and password returns a signed access token, and the user picks their language and text direction. The app then fetches the mobile screens the user may open from the same permission matrix, their assigned districts and the language list.

Stage work from the site

• Receive survey, permit, project, connection, replay and maintenance tasks, confirm receipt, view their files, save data and upload photos.
• Relay survey, permit, project and replay tasks under the same validation rules, with delay justifications where required.
• Email the survey-matching and material-matching forms from the field.

It all runs on the same orders handled in work order management, with its distribution baskets, time limits and re-assignment. The survey stage itself is covered in our Kashfia site survey guide.

Follow-up from the office

ELX sends stage-change alerts via Telegram and, when enabled, WhatsApp to users who can view the stage and have notifications on. A daily digest sets out each user’s orders per stage (see the daily digest guide), and the dashboard shows pending and overdue orders per stage within each user’s scope.

If your field team still runs on chats and phone calls, request a demo to see a survey or execution task travel from assignment to relay. Matrix also provides user training and technical support via WhatsApp.