Next Plus doesn't have a single "permission" switch. Access is controlled by five independent systems that stack on top of each other. You set each one separately, and a person's real-world access is the combination of all of them. Understanding the five layers — and that they're separate — is the key to getting access right and avoiding surprises.

Read it this way: Role decides what you can do. Groups decide what you see. Stations decide where you log in. Certifications decide what you can sign. Licensing decides how many seats exist. They are configured independently.

Every user has exactly one base role. The role is the biggest lever — it defines the core of what the person can do. Next Plus ships with five built-in roles, from least to most privileged:

A note on naming: older material sometimes calls the top tier simply "System Administrator." The current platform separates Admin (full business administration) from SysAdmin (adds infrastructure-level backup and replication). For day-to-day administration, Admin is what most customers use.

When the base role is almost right but you need one exception, you add a custom role on top. A custom role does one thing: it adds (Allow) or removes (Deny) specific capabilities for that user. Two common examples:

For admins: Custom roles are built in Settings → Users → Roles Configuration. Each rule targets a system entity (e.g. Work Orders, Forms), an access type (read / write / execute / all), an optional specific action, and Allow or Deny. Best practice is one base role per user plus a custom role only when needed. Stacking many roles is technically possible but not recommended.

Groups scope visibility, not actions. Put the Assembly team in an "Assembly" group and tag Assembly's workflows and work orders to that group, and those users see Assembly's content instead of the whole plant's.

The thing customers most often get wrong: groups only scope a specific set of things. Group filtering applies to workflows, work orders, work-order templates, configurations, the forum, and user assignment — and nothing else. Forms, parts, stock, tables, and tools are not directly hidden by groups. An Editor opening the Forms list sees every form regardless of group; a form is only "hidden" indirectly, because an operator can't reach the workflow that opens it.

A single system setting — "Users without group see all" (default OFF) — changes how group filtering behaves. It affects both grouped and ungrouped users, which is the part that surprises people:

The gotcha: the name suggests it only affects ungrouped users, but turning it ON also makes grouped users lose access to shared content. Decide this once at implementation. Turn it ON for strict department-by-department isolation; leave it OFF when departments share common content.

Two common models:

For admins: Groups live under Modeling → Groups, not Settings — a frequent point of confusion. Groups can also sync from a SAML / LDAP identity provider by matching an external group ID. Categories (also under Modeling) look similar but are organization only — they carry no security.

Next Plus tracks two seat pools against your contract limits, and exceeding a limit blocks the role change until a seat is freed:

Some users are licensed to a station — a work position on the shop floor — rather than to themselves personally. A station is identified by the browser: it's created automatically the first time someone opens Next Plus on that browser, and stored there. No hardware lock is used, so a different browser, an incognito window, or a cleared browser all look like a new station.

There are two kinds of user:

What happens at a new station:

Every station action — requested, approved, declined, status changed — is recorded, so administrators have full visibility without extra setup.

For admins: Mark a user station-based with the "Requires Station License" flag on their profile, and approve stations in Station Management. The recent platform change is about applying these long-standing rules more strictly and consistently at login — it does not add a new license type, change pricing, limit regular users, or lock usage to specific hardware.

Certifications are qualifications you assign to users. Their main job is to gate signing on specific workflow steps: a step can require a certification, and only users who currently hold it can sign. They also gate work-order status transitions and form permissions.

Define a certification in Settings → Users → Certifications with a name, an optional description, and Days to Expire (0 = never expires). Then assign it to users — the expiry countdown starts from the assignment date. After expiry the user simply can no longer use the cert (its status flips to Invalid); to renew, you reassign it, which starts a fresh window.

Beyond signing, certifications can also be required to move a work order between statuses, and they can be mixed with roles in a form's View / Create / Close permissions. This layer matters most in regulated industries (AS9100, ISO 13485, medical, aerospace), where "only a currently-certified person may sign this inspection" is a compliance requirement.

Roles, groups, stations, and certifications are still assigned inside Next Plus, not in the identity provider — with one optional exception: Role Mapping and Certification Mapping can auto-assign roles or certs from your IdP's attributes if you set them up.

A QC inspector on a regulated assembly line shows all five layers at once:

The result: this person can do exactly the QC job, only on the right line, only from approved terminals, and can sign the inspection only while their certification is valid — all enforced automatically.