Roles and permissions

There are three roles: Admin, Procurement and Department. They are built into the product; you assign people to them, you do not invent a fourth.

Who does what

• Admin — organisation, roles, access, categories, criteria, templates, branding, system settings.
• Procurement — runs purchases: tender, supplier invitations, question round, evaluation, award.
• Department — raises needs and tracks them.

What a department sees, and what it does not

This boundary is the one most often misjudged, so in full:

A department sees every supplier, including their states and contact details. That is deliberate: whoever formulates a need should know who the organisation actually works with.

Not visible:

• Prices and offer details from other tenders
• Suppliers’ qualification data

Also absent: a direct contact form to a supplier. Contact runs through procurement — not out of convenience, but because a running procedure must not be influenced outside the procedure.

If that is too coarse for you

Permissions are role- and department-based. There is no finer cut — nothing like “this person sees only this one category”. Plan around that rather than waiting for it.

The same holds for the interfaces: an API key sees everything across the tenant, with no departmental slice. Issuing a service account grants read access to the whole tenant.

Role changes

Roles belong to functions, not to people. Changing an assignment is a single edit — that is the entire benefit, and it disappears as soon as exceptions get maintained.

One special case: if your instance runs with SSO, the application does not own the role, your identity provider does. What you see here is then a display, not an administration surface — see Sign-in and SSO.