Projects & access
Separate projects and customer views
PMT projects provide a practical boundary between customers, sites, applications, operational subjects and different sharing requirements.
Use project separation where access, responsibility or data purpose should remain distinct.
The basic rule
Separate at the project/token boundary first.
Do not invent a complicated central permission model around every station and check when a clearer source/project boundary will do the job.
One customer or operational subject per project where that fits responsibility.
Examples:
Customer A - core checks Customer B - core checks Website group - external checks Field project - stations
The right project boundary is the one that makes ownership and access clear without creating unnecessary fragmentation.
Send tokens belong to the project they report into.
A send token determines where submitted results land.
Do not reuse one broad send credential across unrelated customers merely for convenience.
Project-specific send access makes revocation cleaner, handover clearer, customer separation easier and temporary assessments easier to retire.
Read access can remain separate.
A customer-facing or stakeholder view does not necessarily need access to every PMT project an MSP or operator can see.
Prefer separation at the project/token boundary.
Project A - private MSP results Project B - customer-shareable results
The MSP can hold authorised read access to A + B.
The customer receives only B.
Combined authorised views do not merge projects.
The PMT read API/webapp can combine results from multiple authorised read tokens where the token/PIN arrangement supports the intended combined view.
This can support MSP NOC views across customers, operator views across related projects, or private + shareable views for an authorised user.
Combining a view does not merge the underlying projects or expand the token scope. Current egress multi-token queries use one supplied PIN for the whole token list; if authorised projects use different PINs, query them separately or use an access arrangement designed for the combined view.
Project separation is practical, not magical.
It provides useful access boundaries without claiming to be a complete customer-portal governance system.
IT CAN SUPPORT
Scoped customer visibility, separate customer/project data paths, private + shareable project patterns and combined authorised reads.
IT DOES NOT BY ITSELF SOLVE
Profile distribution, credential handover, branded portal lifecycle, automatic role inheritance or customer support ownership.
PRESENTATION IS SEPARATE
Project separation controls authorised data access.
Friendly labels, ranges, state mappings and other webapp presentation control how authorised data is shown.
Those are different concerns.
Temporary ASK projects should have an end.
A temporary assessment may justify a temporary project, temporary send token and defined exercise window.
When complete:
- remove the source-side check;
- revoke or expire access no longer needed;
- retain or export results only where they still have a purpose.
Temporary questions should not leave forgotten permanent access behind.
Keep project labels useful but non-sensitive.
Project labels are operational identifiers.
Do not use them as a place for unnecessary secrets or personal data.