User Role-Based Permissions

User roles simplify LDAR by ensuring the right users are recording leaks, fixing leaks and reporting on fugitive leaks

Highlights

  • User roles include Administrator, Operator (operates the device to record leaks), Repairman, and a combined role Operator_Repairman
  • Roles define the logical functions and features of the app available to each user based on their responsibilities in the LDAR program
  • i.e., Administrators can assign leaks to a Repairman and delete and edit any existing user’s records, whereas the Repairman can only create, edit, and delete repairs
  • Roles enable much simpler administration of permissions and roles can be switched for a user at any time

User Roles to Divide and Conquer LDAR Compliance

SMS comes with 4 logical roles which denote each user’s accessible functions and their responsibilities within the LDAR program. SMS roles are defined as such:

Administrator

Administrators are responsible for ensuring that the correct information is being collected/reported and that leaks are being repaired by compliance due dates. This means Administrators have the widest view of all sites, leaks, and repairs and can edit data to fix errors or delete erroneous records in whole.

Accessible functions for Administrator:

  • Add, edit, or delete fugitive sources
  • Add, edit, or delete follow-up observations
  • Add, edit, or delete repairs*
  • View all leaks by timeline and location
  • View all leaks assigned to repairman
  • Export to .PDF or print Repair Work Orders (RWOs) by selection or date range
  • Map fugitive leaks by selection or date range
  • Plan driving routes to leak clusters
  • Export to .PDF or print yearly Directive 060 compliance reporting for well sites

Operator

Akin to a Field Operator, an Operator of SMS is responsible for going into the field and physically checking for leaks while performing daily rotations. This role in SMS is limited to entry of screening records and resulting leak and repair recommendation records. Limiting the role ensures operators stay focused on only the tasks they are best suited to, which is naturally finding leaks while doing daily pad rotations.

Accessible functions for Operator:

  • Add, edit, or delete fugitive sources
  • Add, edit, or delete follow-up observations
  • Change field tags on leaks (in case the tag is damaged or missing)
  • View all leaks by location
  • Map fugitive leaks by date range

Repairman

Repairmen are the repair people, either internal or contracted, tasked with performing fugitive leak repairs at well sites. A Repairman’s role is limited to tracking and locating leaks and entering repairs either within the app itself, or on manual RWOs coded with the leak’s QR code.

Accessible functions for Repairman:

  • Add, edit, or delete repairs*
  • View all leaks by timeline and location
  • View leaks assigned to them for repair
  • View leaks assigned to other repairmen
  • Export to .PDF or print Repair Work Orders (RWOs) by selection or date range
  • Map fugitive leaks by selection or date range
  • Plan driving routes to leak clusters

Operator_Repairman

Often it is preferrable to seperate the operator and repairman roles so each role focuses solely on what they are best trained to do; however, sometimes in smaller entities (or entities which allow operators to perform repairs) it is most efficient to have a combined role. Thus the Operator_Repairman role exists to combine the Operator and Repairman roles together allowing for greater efficiency in the field.

Accessible functions for Operator_Repairman:

  • Add, edit, or delete fugitive sources
  • Add, edit, or delete follow-up observations
  • Add, edit, or delete repairs*
  • Change field tags on leaks (in case the tag is damaged or missing)
  • View all leaks by timeline and location
  • View leaks assigned to them for repair
  • View leaks assigned to other repairmen
  • Export to .PDF or print Repair Work Orders (RWOs) by selection or date range
  • Map fugitive leaks by selection or date range
  • Plan driving routes to leak clusters

*controls exist to prevent illogical workflow actions from being permitted. For instance, once a leak is repaired and uploaded it can not be deleted as in our experience there’s rarely a good reason to delete a repaired leak once synced.