Protecting field-service operations

Security in a work-order system concerns the information people use to organise and carry out service work. Customer addresses, access arrangements, job photos, technician activity and financial records can pass between the office, field team and customer. A useful review considers each handover, the permissions involved and the copies that may exist outside the application.

This page explains the WorkOrderPro security approach and provides a practical evaluation guide. Use it alongside the applicable agreement and current privacy information. Where a contractual requirement depends on a particular control, certification, retention period or recovery commitment, obtain current written confirmation before purchase. A general overview is not a substitute for the specific evidence your organisation needs.

Start with the records and roles that matter

Identify the information your team intends to place in the system. A service company coordinating residential repairs may handle a different mix of details from a contractor maintaining commercial equipment. Include customer contacts, site information, attachments, internal notes and the financial records needed for your workflow. Avoid assuming that every job requires the same information or the same access pattern.

List the roles that will handle those records. Consider office administrators, dispatchers, field technicians, billing staff and any customer-facing users. Describe what each role needs to do rather than granting broad access because it is convenient during setup. A technician may need to understand an assigned visit without needing every customer's invoice history.

Use synthetic records for initial permission checks. Create a representative customer, site and job without real access codes or sensitive documents. Give each test account the intended role and inspect the actual behaviour. This lets you evaluate the workflow without exposing live information merely to demonstrate that a restriction works.

Understand the company workspace boundary

WorkOrderPro is organised around company workspaces, with application queries and authorisation controls designed to restrict records to the appropriate business account. That separation is relevant across lists, detail views, updates and downloads. A record should not become accessible merely because a person knows or guesses its identifier.

Within a company, role and assignment checks provide additional boundaries. These answer a different question from company separation: which person in this business should access a particular function or record? During evaluation, test both. A technician being unable to see another business's customer is important, but it does not by itself establish that the same technician has the right access within their own company.

Ask about the specific surfaces your team will use. A list, exported document, photo link and mobile update can follow different paths through a system. Include them in the trial where they matter to your process. Avoid treating a hidden navigation link as complete evidence of a record-level restriction.

Use individual accounts and deliberate role changes

Individual accounts support access management and make recorded actions easier to attribute. Create accounts for the people who need to work in the system and use the role appropriate to their responsibilities. Review any administrative access granted during setup instead of assuming it should remain indefinitely after the rollout.

Use the authentication and multi-factor options available for the relevant account and confirm how they work in your setup. Protect recovery channels as well as the sign-in process. If a staff member loses access to their email or device, the person handling recovery should follow an agreed process rather than sharing another colleague's password to keep work moving.

Treat role changes as part of normal operations. Someone moving from dispatch to field work may need a different view of the business. Someone leaving a contract may need access removed promptly. Decide who is responsible for making and checking those changes, including any related integrations or devices outside the main application.

Check assignment-sensitive information from a technician account

Technicians need information that helps them carry out assigned work. Site details, relevant history and job preparation should be understandable without exposing unrelated records simply because they are stored in the same workspace. Evaluate the actual assignment and customer relationships your business uses, including supporting crew members where that workflow applies.

Test a representative reassignment. Confirm the resulting job view and consider what information the first technician may already have downloaded or received through another channel. Access changes in an application cannot automatically recall every external copy. Your staff process needs to address those copies where their continued availability would matter.

Use real role accounts in a controlled trial rather than relying on an administrator to describe the technician experience. Include both an allowed action and a nearby action that should be restricted. This gives the rollout team concrete evidence and helps identify a configuration misunderstanding before live customer records are introduced.

Review customer-facing access separately

A customer-facing view serves a different audience from the internal office record. Review which jobs, quotations, invoices and photos the customer should be able to access under the configured permissions. Keep financial access and the ability to request or change work distinct where the product provides separate controls.

Check permissions through more than one route. If access to invoices is disabled, include invoice lists and document downloads in the review. If a customer should see only selected job photos, inspect the actual customer view and a direct link where relevant. Testing a single screen does not establish the behaviour of every sharing path.

Confirm the customer identity and recipient before sharing information. A property manager, tenant, landlord and site contact can have different responsibilities. The software's records need to reflect the relationship your business intends to use. A carefully configured permission cannot correct a customer record that associates the wrong person with the wrong account.

Handle job photos as work records

Job photos may reveal customer premises, equipment identifiers, people or access arrangements. Give the field team a clear capture purpose and a practical standard for useful images. The aim is to document the work with enough context for the authorised reviewer, while avoiding unrelated material that adds no value to the task.

WorkOrderPro's job-photo workflows use access controls and private-file delivery where applicable. Confirm the exact photo path and recipient view used in your rollout. Do not assume that a file copied into email, a personal gallery or another messaging service retains the application's access restrictions after it leaves the system.

Review both storage and sharing questions during a trial. Can the authorised office user retrieve the right image? Does the customer see only the intended selection? What happens when permission is removed or a record is deleted through the supported process? Use synthetic material and record the observed behaviour rather than testing with private customer photos unnecessarily.

Understand mobile storage and account switching

A mobile workflow may keep downloaded information and pending changes on the device so supported tasks can continue when connectivity is interrupted. That creates a device-level responsibility as well as a server-side one. Secure the device and understand which actions are saved locally, pending submission or confirmed by the server.

Test account switching if devices are shared. The new user should receive the appropriate current account context, and the team needs a clear procedure for pending work belonging to the previous account. Do not assume that deleting the app is the correct response to every sync problem; it may remove local information that has not yet reached the server.

Include device loss in your operating procedure. Decide who disables the relevant access, checks recent activity and contacts support. Consider documents or photos copied outside the app as part of the assessment. A lost phone is a practical incident the team should know how to report, not a situation where each technician needs to invent a response.

Distinguish a successful action from a completed handover

A security review should also examine whether interrupted operations leave understandable records. A technician may submit a change while the connection is unstable, or a dispatcher may retry an action after an uncertain response. The user needs to distinguish an acknowledged result from a pending or failed attempt.

During evaluation, test the recovery path for important actions using synthetic data. Verify that retrying does not create an unintended second charge, duplicate job or misleading record. Different operations can use different safeguards, so focus on the actions that matter to your business rather than assuming one successful retry demonstrates every possible case.

Record unresolved outcomes for investigation. If the interface and the office record disagree, preserve the relevant job reference and approximate time. Avoid making repeated changes simply to make the screen look correct before anyone has checked the underlying result. Clear support information can help the issue be investigated without sending a complete customer database.

Protect exports and information sent outside the application

Exports are useful for accounting, review and migration, but they create another copy of information. Decide who needs export access and where exported files should be stored. An application permission cannot continue controlling a spreadsheet that someone has copied into a personal folder or forwarded to another recipient.

Use the minimum material needed for the external task. A supplier quotation may require a description and selected images without the customer's complete history. A management review may need aggregated figures rather than an unrestricted list of contacts. Agree the intended content and recipient before generating or sending the file.

Include working copies in your retention and staff-change processes. Ask where downloaded documents remain on office computers and field devices. If the business uses another approved archive, define its access and review arrangements. Treat those decisions as part of the operating process rather than assuming all information management ends at the export button.

Review integrations through their actual permissions

An integration can involve accounting, payments, email, calendars or another business tool. Identify the account being connected, the information exchanged and the operations it is authorised to perform. A connection used only to send an invoice has a different purpose from one that can modify a wider set of business records.

Use the appropriate setup process for credentials and authorisation. Do not paste passwords, private API keys or payment credentials into ordinary job notes or a public contact form. Assign responsibility for maintaining the connection and for revoking it when it is no longer required. The person who originally configured an integration may not remain with the business indefinitely.

Test failure and reconciliation as well as connection success. If another provider rejects an operation or returns an uncertain result, the office needs to know what was completed and what requires review. A successful login to the provider is only one part of verifying a useful and controlled integration.

Ask concrete questions about retention and recovery

Retention and recovery requirements depend on the record and the service arrangement. Ask about the relevant categories, deletion behaviour, backup handling and the process for requesting assistance. Do not infer a fixed retention period or restoration commitment from a general statement that a service uses backups.

Describe your requirement in terms that can be assessed. Which records need to be recoverable? From which kind of event? Who is permitted to request restoration? What evidence or written commitment does your organisation require? These questions are more useful than asking only whether backups exist, because they connect the control to the business decision.

Keep the distinction between application behaviour and your own archive. A supported deletion action may not immediately remove every historical backup or external export. Clarify the process before promising a customer that every copy is gone. Coordinate financial or contractual retention decisions with the person responsible for those obligations rather than applying one rule to every file.

Prepare for account or security incidents

Use the security contact on this page to report a suspected vulnerability or account-security concern. Include a concise description, the relevant product area, approximate time and enough information to investigate safely. Share only material necessary for the report, and avoid sending passwords, private keys or unrelated customer records.

If you discover a potential access issue, stop at the minimum information needed to describe it. Do not continue opening other people's records to establish how much information might be available. Report the observed behaviour and let the appropriate investigation process determine the wider impact. An effective report does not need to expose more data than the initial observation.

Your organisation should also define its internal incident contact and response process. Staff need to know what to do when a device is lost, a document is sent to the wrong person or an account behaves unexpectedly. Privacy-related reporting obligations depend on the circumstances; use the POPIA operations guide and appropriate current advice for that assessment.

Evaluate availability and change requirements explicitly

Service availability matters when the office and field team depend on the same records. Explain which parts of your workflow are time-sensitive and what you need to know about maintenance, support and incident communication. Do not treat an observed fast response during one demonstration as a contractual availability commitment.

Ask how your team should work when a required connection is unavailable. Supported offline actions may help with some field tasks, while another action may need a live connection. Test the relevant process and agree the operational fallback. Avoid describing every interruption as equivalent: device failure, network loss and a third-party provider issue can require different responses.

Include important changes in your rollout review. A new integration, additional role or different sharing process can change the information involved. Revisit the relevant permission and handover checks when the workflow changes materially. The goal is a repeatable review practice that stays connected to how the business actually works.

Keep evidence and responsibilities easy to find

Maintain a short record of the controls demonstrated, the questions answered in writing and the requirements that remain open. Include dates and the context of the evaluation. This helps a future administrator understand what was verified without assuming that an old screenshot or informal statement applies to every later configuration.

Give each operational responsibility an owner. The software provider handles parts of the service, while your business controls staff access decisions, device use, information entry and external sharing. Describe the actual division in the applicable agreement and your internal procedure. A responsibility that belongs to everyone in theory can be missed by everyone in practice.

Use the following review table to organise questions before a wider rollout. It is a procurement aid, not a certification checklist or a claim that every possible requirement is included in a standard subscription. Obtain the particular evidence needed for your decision and confirm any separate service commitments before relying on them.

Frequently asked questions

Does the security overview certify our business's compliance?

No. It describes the product approach and helps structure an evaluation. Your business must assess its own information, activities and obligations. If a contract requires a particular certification or independently assessed control, request current written evidence and confirm the requirement before purchase.

Should all staff receive administrator access during setup?

Assign access according to the work each person needs to perform. Review temporary setup permissions before rollout and test the actual role experience. Broad access may be convenient initially, but it should not become permanent by accident. Give someone responsibility for approving and reviewing role changes.

Are internal job photos automatically suitable for customers?

No. Review the intended recipient and selection. An internal photo may include notes, context or private details that are unnecessary for the handover. Use the supported visibility controls and inspect the actual customer view. Remember that files exported or forwarded elsewhere follow the controls of those other systems.

What should we do if a technician loses a device?

Follow your incident process, notify the responsible person and remove relevant account access through the supported controls. Assess any local records or exported files that may be involved. Preserve useful information for investigation and contact support when needed. Do not assume one password change addresses every possible external copy.

Can we verify permissions without using live customer data?

Yes. Use synthetic customers, sites, jobs and documents with representative relationships. Test allowed and restricted actions with the intended roles. This provides useful evidence without exposing real records merely to demonstrate a control. Keep the test context and unresolved questions in your rollout notes.

Does an export keep the application's access restrictions?

A downloaded file is a separate copy. Decide where it will be stored, who may receive it and how it will be retained or disposed of. The application cannot automatically enforce its role permissions in every external folder, email account or messaging tool used after export.

What information belongs in a security report?

Provide the affected product area, relevant account or job reference where appropriate, approximate time and a concise description of the observed behaviour. Include only information needed to investigate. Do not send credentials or continue accessing unrelated records to expand the report. Use security@workorderpro.co.za for the concern.

Which security questions should we resolve before rollout?

Confirm role access, customer sharing, device handling, integrations and the retention or recovery requirements important to your organisation. Test the relevant workflows and obtain written answers where contractual commitments are needed. Assign the internal responsibilities so the operating process continues after the initial setup.