Business Process — Who Does What When
This document explains how to run the platform in your organization. It covers roles and sequence, not screen usage.
The tutorial is "try it once alone." This document is "keep running it as a team." Handover points where responsibility changes are marked.
Three roles, that's all
| Role | Screen label | Responsibilities |
|---|---|---|
| ADMIN | System Administrator | Accounts, security, equipment master data, system configuration — all of it |
| API | API Developer | Third-party system integration. Call API with tokens |
| USER | General User | Read-only. No change permissions |
It doesn't exist in the source. If you need "some permissions for a supervisor," solve it with security policy (permission groups), not roles → Security Management.
The menu visible to each role differs → Login and Screen Layout.
Lifecycle — Three phases
The whole process by role looks like this. Arrows crossing swimlanes mark handover points.
1. Deployment and Commissioning — Once, but do it right
| Step | Task | Owner | Deliverable |
|---|---|---|---|
| 1 | Installation | Implementation | Running platform → Installation |
| 2 | Replace all default passwords | Implementation | Handover document → Change Initial Password |
| 3 | Finalize ID naming rules | Implementation + Field | Naming rules document → Domain ID Rules |
| 4 | Register sites → equipment → tags | Implementation | Equipment master data |
| 5 | Connect Edge and validate collection | Implementation | Values appear on screen |
| 6 | Set alarm thresholds | Field | Alarm definitions → Alarm Management |
| 7 | Issue accounts and assign roles | ADMIN | User list → User Management |
| 8 | Acceptance inspection | Field | Acceptance document |
IDs embed themselves throughout the screen, API, and reports. Hastily assigned IDs stick around for years. Create the rules as a document before you start registration.
2. Normal Operation — Recurring tasks
| Frequency | Task | Owner |
|---|---|---|
| Daily | Check and respond to alarms, check for collection gaps | Field |
| Weekly | Review disk and resource trends → Monitoring | ADMIN |
| Monthly | Backup recovery drill, account cleanup | ADMIN |
| Quarterly | Password rotation → Credential Rotation | ADMIN |
The most common failure is having backups but never testing recovery. That matters more here with three storage layers → Database Model.
3. Changes and Expansion — When equipment is added or modified
| Task | Sequence |
|---|---|
| Add equipment | Register in master → tags → validate collection → alarms |
| Change tag meaning | Check first that old and new data won't mix with different units |
| Add integration | Issue API account → token → set IP restrictions → API Manual |
If you change the meaning of a tag in use, old and new data mix under the same name. Reports cannot tell them apart. Create a new tag.
Handover Points — Breakdowns often happen here
| Handover | What to pass on |
|---|---|
| Implementation → Field | Account list, storage location of changed passwords, ID rules document, acceptance document |
| Field → System Administrator | Incident contact path, how to generate diagnostic tarball (./doctor.sh) |
| Staff transition | All of the above + recent change history |
Write where they are stored. Pass the values through a separate secrets management system.
Common breaking points
| Symptom | Usual cause |
|---|---|
| "I don't know who changed this" | Shared accounts. Create one account per person |
| "So many alarms nobody looks at them anymore" | Thresholds set at go-live and never touched. Adjust quarterly |
| "Data is missing from when?" | Collection gaps not checked daily. Add it to the daily checklist |
| "I took over but don't have the password" | Handover document didn't say where to find it |