All products

Sign-In & Access

Give staff and customers their own sign-in and decide which records they can view or change.

Business workspacePaint supplier demo

The right action, for the right role.

A shared workspace, with different responsibilities.

Viewing as Manager. Change the demo role above, then try a payment or purchase approval.

RoleSales recordsRecord paymentApprove purchase
ManagerSalesPaymentApproval
SalesSalesPaymentApproval
FinanceSalesPaymentApproval

Your invoice, payment and purchase decisions will appear here with the acting role.

UI permission simulation only. Production sign-in and server-side security are not connected.

Demonstration only. Changes stay in this example; nothing is sent.
Adapted from Ceus One Demo · fictional data · no live transactions

A clearer operating result.

Useful when the operation needs more than another tool.

  • Staff share a login to access operational records.
  • Customers need private views within the same application.
  • Removing a person from the team does not remove their access.

What changes

  • Access tied to individual accounts
  • Customer and staff permissions separated
  • An explicit process for joining and leaving

The practical details.

What’s included, what it connects to and how it works.

How this foundation works.
  1. Sign in with an individual account
  2. Check organisation and role
  3. Allow the permitted record or action
  4. Revoke access when membership ends
How far can we take it?

A starting point

Sign-in, invitations and a small set of roles, with access checks for both viewing and changing records and a tested removal process.

Additional work to consider

Enterprise sign-in, delegated administration and permissions per record require a more detailed access model.

What can it connect to?
  • Chosen identity provider
  • Organisation and membership records
  • Application data access
  • Invitations and account recovery

We’ll check what your existing tools let us access before including a connection in the plan.

Is hiding a button enough to restrict access?

No. The application must check permission when reading or changing the underlying record. Interface visibility is only one part of the experience.

Can we keep our existing staff sign-in?

Where the identity provider supports the required connection, it can be retained. Confirm the account lifecycle and available access information during discovery.

Start with the problem.

No brief or technical diagnosis required.

Tell us what's stuck