People and roles

The People tab of org settings lists everybody in the org, their role, where that role came from, and when they were last seen.

Anybody in your CRM can sign in

There is no invitation step, and that is deliberate rather than an omission.

Anybody in your Zoho org is already a legitimate user of the CRM, and an import writes through the widget SDK as them — so they can do nothing in Zoho through Sloose that they could not do by hand in Zoho. Gating on a second list of who is allowed would be security theatre over an access decision Zoho has already made.

What matters is what happens afterwards, which is what this tab is for.

The four roles

Ranked, so each includes everything below it.

Role	Can
operator	Run imports, read configuration.
builder	Everything above, plus create and edit projects and schedules.
admin	Everything above, plus curate modules, annotate fields, manage libraries, tokens, members and billing.
owner	Everything above, plus start the trial.

The first person to sign in to a new org becomes its owner. After that, where the org follows Zoho profiles, somebody with the CRM’s Administrator profile becomes an admin and everybody else an operator.

Changing somebody’s role

An administrator changes it on the People tab. Four rules stop an org escalating sideways or locking itself out:

• You can lower your own role, not raise it. Promoting yourself would defeat having roles at all. Stepping down is a real thing people do — handing over, or shedding admin rights they no longer want — so it is allowed.
• You cannot change somebody who outranks you, or grant a role above your own.
• The org cannot be left without an owner. Make somebody else an owner first.
• Restore access before changing a role on somebody who has been revoked.

Each refusal says which rule it hit: SELF_CHANGE, OUTRANKED, LAST_OWNER, ACCESS_REVOKED.

A manual role sticks

Setting a role by hand marks it as manually assigned, so signing in again does not undo it.

That matters on an org following Zoho profiles: without it, promoting somebody would last until their next sign-in and then quietly revert, which is the kind of thing nobody notices for a month. The tab shows where each role came from.

Removing somebody

Revoking access blocks the member. Their next request is refused, and — this is the important part — signing in again does not let them back in. Since anybody in the CRM is otherwise admitted automatically, deleting a membership would achieve nothing; they would simply sign in once more.

So the membership is kept and marked, which also makes the removal auditable and reversible. An administrator can restore it later, and the person keeps the role they had.

You cannot revoke your own access, and you cannot revoke somebody who outranks you.

This is not the same as removing them from Zoho

Revoking access here stops somebody using Sloose. It does not touch their CRM account, and it does not undo anything they imported.

If somebody is leaving the organisation, removing them in Zoho is the actual control; this is for the narrower case where they should keep their CRM but no longer be importing into it.

Where the roles are enforced

On the server, on every request — not once at sign-in.

Every org route re-reads the membership as it handles the request, so a demotion or a revocation takes effect immediately rather than at the end of the offending person’s eight-hour session. That is one indexed lookup per request against a control that would otherwise be worth very little.

The same applies to an API token: it acts as the member who created it, so revoking that person’s access stops the token too.