Six things have to be true before one action runs. Not any of them — all of them.

Access here is not a role name. What decides whether someone may do something is the organization’s licence and the permission group bound to the position they hold, resolved when they sign in. This page follows one ordinary action all the way through the conditions that let it happen.

The action Open the payroll screen and change a wage rate

Every one of these, before the action runs.

  1. Does the account exist at all?

    Nobody signs themselves up. Self-registration is switched off, so an account exists because someone in the organization provisioned it — which makes the list of accounts a decision rather than a consequence.

  2. Did the sign-in itself succeed?

    One authorization server, and every application in the suite is a client of it — so one sign-in covers the suite rather than each application keeping its own. Passwords carry a minimum length and complexity rule and cannot repeat the last five. An authenticator-app second factor can be enrolled, with recovery codes; it is enrolled per user rather than enforced across the organization.

  3. What organization does that account belong to?

    The account resolves to an employee record, and that record carries the organization. Every query the applications run is scoped to it, which is why one deployment can hold more than one organization without their records meeting.

  4. Is the organization licensed for this application?

    An encrypted licence file, validated on upload against the organization name and an expiry, names the modules that exist for that organization. If it has expired, privileges drop to read-only rather than the applications simply continuing.

  5. Which permission group does the seat hold?

    Groups are bound to positions in the org chart, not to accounts. The employee holds a seat; the seat holds the group; the group carries the applications and the privileges. A change of holder is therefore not a change of permissions — and there is no per-person exception list to maintain.

  6. Does the group grant this exact action on this exact form?

    Not a role name. The group lists each form individually and, within it, each action individually — read, create, update, delete, download. Read on payroll and update on payroll are separate grants, and one does not imply the other.

Only then The wage rate can be changed. Any one of the six failing means the screen does not open, or opens without the action on it.

Evidence · the sixth condition Each form listed on its own, and inside it each action granted separately.
A continON permission group shown as a matrix of forms and actions — read, create, update, delete and download — each individually granted.
A continON permission group: every form it covers, with read, create, update, delete and download granted individually rather than bundled into a role.

When the caller is an application rather than a person.

Then there is no seat to resolve, so the grant is made to the application itself and listed where it can be seen: which identity and API scopes it was given, when it was granted, when it expires, and the control that withdraws it. Access that cannot be seen cannot be governed, and this is where it is visible.

Per-application access grants issued by the continON identity service, each application listing its identity and API scopes.
Client application access in continON: each application with the identity and API scopes it was granted, the date it was created, the date it expires, and the control to revoke it.

What is actually kept, and what it covers.

A running request keeps its own trail
A process instance records the transitions it made and the version of the definition it ran under, so which rules a given request was decided by stays answerable afterwards. Process Builder
Employment assignments are historized
The current assignment is flagged and the previous ones stay on record with their dates — so who held a seat at the time something happened is a question with an answer. Employment & contracts
Acceptance of the disclaimer is recorded
The notice users must accept is published once for the organization, and each acceptance is logged against the user who gave it. Enterprise setup

What this page is not claiming.

  • No certification is claimed. continON is not presented here as certified, audited or assessed against ISO 27001, SOC 2, HIPAA, PCI DSS or any other scheme, and no compliance badge appears on this site.
  • Two-factor authentication exists as an authenticator-app enrolment per user. It is not described as organization-wide enforcement, and there is no SMS or email second factor.
  • Federation with an external identity provider is not offered. Wiring for it exists in the codebase but is currently disabled, so it is not presented as a capability you can buy today.
  • Not everything is audited. The trails named above are specific ones that genuinely exist; this page does not claim a comprehensive audit log across every screen and every field.
  • No encryption property is asserted beyond what is visible: public hostnames are served over TLS, and stored external-API keys are encrypted at rest. Nothing further is claimed about data at rest or in transit.

Bring your security review.

A working session on a sanitized tenant with your own questions: how a group is built, what a seat actually opens, and what an application grant looks like when it is revoked.