¶ Access and Provisioning
This internal page covers how Observit teams should handle OEC access requests for customers, partners, and installers.
Use it together with the customer-facing Access and Roles page so we keep external guidance simple and internal handling consistent.
Keep the following details in internal documentation only:
- the exact provisioning system or admin interface used
- internal role naming that is not customer-safe
- service ownership boundaries between support, delivery, and operations
- temporary diagnostic access patterns
- deprovisioning and rollback steps tied to internal tooling
Before creating or changing access, confirm:
- requester name and organization
- customer and fleet scope
- required workflows such as live view, playback, reports, or administration
- whether the request is temporary or permanent
- approving service owner or customer administrator when required
Use these rules by default:
- grant the smallest access scope that supports the task
- avoid broad multi-customer visibility unless there is an approved operational reason
- use temporary access for installers, rollout staff, and incident support where possible
- separate admin rights from investigation or operator rights
- document exceptions clearly in the case or handover record
¶ Standard Provisioning Checklist
- Validate the requester and approver.
- Confirm the correct customer, depot, or fleet scope.
- Assign the lowest suitable permission set.
- Record whether the access is time-limited.
- Tell the requester what to test after sign-in.
- Link the request to any related incident, rollout, or onboarding case.
After provisioning, confirm that the user can:
- sign in successfully
- see the correct customer or depot scope
- open the expected vehicle list
- access the approved workflows only
- avoid seeing functions they were not meant to receive
¶ Handover Notes
When handing access over to a customer, partner, or installer, include:
- what was granted
- which fleet area it applies to
- whether the access is temporary
- who owns future changes
- where the user should go for support
Review or remove access when:
- an installation project is completed
- a partner engagement ends
- a temporary investigation is closed
- a customer changes ownership or scope
- a user no longer needs admin rights