Skip to content

Central permission check

One permission check for every access

If you want to run all your processes on one platform, you need to settle whether IT, for example, would then see HR cases. That separation has to be secured technically, not just organisationally. In nexxcite, every access therefore passes through a central permission check, including access by the AI.

  • Permissions defined as rules
  • Down to record, field and action
  • Complete workspace separation
  • SSO, LDAP, two-factor
Book a live demo Architecture and governance

Granularity

Permissions can be set in fine detail

Down to the record Read, create, edit, delete Limits per record type, defined as a rule: the procurement team lead sees only requests for their own cost centre.
Down to the field Visible, editable or simply not there One personnel file, two views: the line manager sees absences, while salary fields stay with HR.
Down to the action Individual rights for buttons and flows The team may edit the request. Only someone with approval rights may trigger the approval.

The principle

Permissions are defined as rules

In many systems, a permission is a tick in a matrix: a role may read a record type, yes or no. That works until the first special case comes along.

"Team leads see their own team's requests, the neighbouring team's when covering, everything in the department on escalation, and HR does not see requests about themselves." This is what permissions often look like in practice, and a matrix cannot express them.

In nexxcite, a read permission is an expression, a rule that is evaluated on every access. It takes account of relationships, roles, field values and the person asking. The special case thus becomes one rule among others.

  • Read, create, edit and delete rights configured separately
  • Rules follow relationships: only cases for your own cost centre
  • Roles can include other roles
  • With several roles, priority decides
  • Delegation built into the model, acting on behalf traceable
  • Rights on the configuration itself, not just on records

Security

One permission check for every access

Whether someone works in the user interface or the customer portal, another system connects through the interface, an AI assistant answers a question or an automation runs overnight: every access passes the same permission check. This applies to AI as well.

Central permission check
  • Role
  • Area
  • Record
  • Field
  • Action
One rule for every way in
Your data One store, cleanly separated

Permissions down to the record

Roles define which records someone may read, create, edit or delete, for example “own cost centre only”.

AI without special rights

An assistant sees exactly what its user may see. Whatever the permission check filters out is not available to AI.

Sign-in to your standard

Single sign-on with existing company accounts, connection to your directory and two-factor authentication.

Isolation

A workspace cannot detect other workspaces

Separation here means more than invisible data: other workspaces cannot tell that a workspace exists at all.

What a workspace does not see

For HR, there are no IT tickets. They are neither greyed out nor locked. They are simply not there.

  • No records in lists or search
  • No other record types in the navigation
  • No hits in global search
  • Via the API: "not found" instead of "forbidden"

What that makes possible

Departments work on the same platform without having to give each other insight into their data.

  • HR processes next to IT processes
  • External portal users next to internal staff
  • Several subsidiaries in one installation
  • Separate administration per workspace possible
Areas and themes

AI without special rights

Whatever the permission check filters out does not exist for the AI

The assistant searches with the rights of the person asking, never more. On top of that, you decide per assistant which data areas it knows about at all.

AI at work

What comes with it

Security you can verify yourself

The core

Exactly one place where permissions are enforced

The permission check is part of every database query and does not sit in the interface. Data a person may not see is never loaded. Interface, customer portal, REST API, AI assistant, MCP and automation all use the same check. No route in can bypass it.

  • UI
  • Portal
  • REST API
  • AI assistant
  • MCP
  • Automation

Sign-in your way

Single sign-on via OpenID Connect, LDAP and Active Directory, two-factor authentication.

Roles that build on each other

Roles include other roles. If someone has several, priority decides.

Credentials in one place

Keys for other systems are managed in one place with their own permissions, not spread across individual flows.

Background flows checked too

Background jobs and scheduled flows run in a defined security context, meaning with clearly defined rights.

No hints at hidden data

Hidden records return "not found", not "forbidden". Even that distinction would reveal they exist.

For your security team

How your security team can check the principle

The test covers one statement: there is exactly one place where permissions are enforced, and every route in passes through it. This can be tested, and we are happy to do so with you in a technical session.

  1. 01

    Create a restricted role

    For example: procurement team lead, sees only their own cost centre, no HR data.

  2. 02

    Query through the UI

    In lists, search and dashboards, you check what shows up and what does not.

  3. 03

    Query through the API

    The same data via REST API in the context of the same role. Anything hidden returns "not found".

  4. 04

    Ask the assistant

    "Show me all open requests." The answer contains exactly what the role may see.

  5. 05

    Compare the results

    All three routes return the same result, because they pass through the same permission check.

FAQ

Questions from security and data protection

Does IT administration automatically see every workspace?

Not necessarily. Administration can be separated per workspace, and permissions apply to the configuration itself as well. You decide who may manage which workspaces.

What does an external portal user see?

Only what their role allows, typically their own cases. Internal structures, other customers and other workspaces do not exist for them.

Can an AI assistant see more than the person using it?

No. The assistant works with its user's rights. You can also define per assistant which data areas it knows about. This narrows its access further, it never widens it.

How does sign-in connect to our identity management?

Via OpenID Connect for single sign-on, plus LDAP and Active Directory for user and group data. Two-factor authentication is supported. nexxcite manages roles and permissions.

Can we separate several companies in one installation?

Yes. Several subsidiaries can work in one installation with strictly separated data and, if you wish, separate administration.

Live demo

In the demo, we test your workspace separation

Bring a specific case, such as two departments that must not see each other's data. It is a good way to test the permission model.

Book a live demo On to integration
  • Your role model, not an example
  • Tested via UI, API and AI
  • Bring your security team