Limiting technician view/edit permissions — how granular?

I am evaluating the FieldPulse permission model for our field service deployment. The current documentation describes three primary roles: Admin, Manager, and Technician. However, I require clarification on the following points:

  1. Can the Technician role be restricted to view-only access for work orders not assigned to that specific user?
  2. Is it possible to prevent technicians from editing customer contact information while still allowing them to add job notes?
  3. Can field-level permissions be configured to hide pricing data (labor rates, parts markup) from technician view entirely?
  4. Are there any plans to introduce custom role definitions beyond the three standard roles?

I have confirmed that we are running FieldPulse version 3.2.1 (web) and our mobile fleet is standardized on iOS 17.6 with app version 3.2.0 (build 4821). Our compliance requirements stipulate that technicians must not have visibility to customer billing history or internal cost data.

Please advise on current capabilities and recommended configuration patterns. Reference to specific documentation sections or policy templates would be appreciated.

Parents
  • It is worth noting that the pricing visibility limitation Priya identified may have compliance implications depending on your jurisdiction and contractual obligations. From a governance perspective, I would recommend documenting this as a known control gap in your internal risk register.

    Anita, you may wish to reference Managing User Roles and Permissions for the current permission matrix, though I have confirmed the documentation does not address field-level granularity beyond what Priya outlined.

    Additionally, it is worth noting that API access (if provisioned for your account) inherits the requesting user's role permissions. If you are considering custom integrations to enforce pricing restrictions at the data layer, ensure your API keys are scoped appropriately and audit access quarterly.

Reply
  • It is worth noting that the pricing visibility limitation Priya identified may have compliance implications depending on your jurisdiction and contractual obligations. From a governance perspective, I would recommend documenting this as a known control gap in your internal risk register.

    Anita, you may wish to reference Managing User Roles and Permissions for the current permission matrix, though I have confirmed the documentation does not address field-level granularity beyond what Priya outlined.

    Additionally, it is worth noting that API access (if provisioned for your account) inherits the requesting user's role permissions. If you are considering custom integrations to enforce pricing restrictions at the data layer, ensure your API keys are scoped appropriately and audit access quarterly.

Children
No Data