Service Areas and Access

A service area identifies the counterparty context used by an operational case. It carries a name, code, contact, address and eligibility note within an organization. App Administrator maintains that reference information so Utility Coordinator can select the intended area when preparing a case. The organization supplies its own identity, active setting and time zone for the operating team.

Staff membership links a team member to the organization and platform user. That connection matters when the current user’s assigned cases are selected or an actor’s authority is checked. Role responsibility determines who prepares work, who reviews independently and who reads the evidence. Administrative membership alone does not confer operational approval or execution authority.

• Area identity. Keep the service-area code stable and make the eligibility note useful to the coordinator. Check the organization before using an area on a case. Similar area names need enough context to distinguish the operating scope and the contact responsible for it.
• Staff membership. Link the person doing the work to the correct platform user and organization. Keep the active setting current. The case owner is a team-member reference, so a personal view must resolve that membership before comparing the assigned owner.
• Separated authority. Utility Coordinator prepares assigned organization and draft scope. Authorized Utility Supervisor reads the domain and makes approval decisions through guarded actions. Auditor reads authorized evidence without writes or execution, while administrators maintain configuration and user access within their own responsibilities.

Agree who maintains service-area identities and what an eligibility note must explain before work is routed there. Choose the time-zone convention used to interpret reported events and interval ends. Confirm that imported area and organization codes retain their intended meaning so a review does not depend on matching display names alone.

Assign the independent supervisor who can review the coordinator’s work and confirm that their scope includes the relevant records. Test the user-to-member link used by personal case views. Decide how a membership change is reflected before the person acts on another case, preserving earlier decision history for audit. Keep user provisioning separate from the business decision the supervisor makes.

Create an illustrative service case in the north service area. App Administrator confirms the area’s organization, code and eligibility note, then checks the coordinator’s user membership. Utility Coordinator selects the area and prepares the case. The independent supervisor should be able to inspect authorized source evidence and make a decision through the guarded workflow without direct record-editing rights.

Repeat the case with a similarly named area in another organization. Confirm the selected code and intended scope before proceeding. Then ask Auditor to inspect the decision and action receipt while attempting no mutation. Finally, change the preparer’s membership in a controlled rehearsal and recheck access. Historical evidence should remain understandable without granting the person authority over new work outside their permitted scope.

• Service Areas — Active area identities with organization, contact and eligibility context.
• Team Members — Active staff membership and user links for authorized access checks.
• My Service Cases — Assigned work resolved through the current user’s team membership.

Begin with case intake and evidence review, then rehearse the responsibilities in roles and access.