Teams and organisations
An organisation is the account an agency shares. It owns the listings, the portfolio site, the enquiries, the API keys and the bill, and it is what makes those things survive a person leaving.
A person belongs to one organisation.
The three roles
| Role | May do |
|---|---|
| Owner | Everything, including billing and removing an admin |
| Admin | Manage members, listings, the site and enquiries |
| Member | Work on listings and enquiries |
The distinction that matters is between admin and member, and it is not about seniority. An admin can change who else has access. That is the power worth restricting, and it is unrelated to how many properties somebody handles.
There is one owner. It is the person the invoice belongs to.
Adding somebody
Members are added by email address. A person who already has a Skautik account joins with it, keeping their own sign-in and their own two-factor setup: an agency should never be sharing one login, and this is what makes that unnecessary.
Add people as members. Promote to admin when somebody actually needs to manage access, which is usually one or two people rather than everybody senior.
Removing somebody
Removing a member ends their access immediately. It does not delete anything they created: the listings, the enquiries and the replies belong to the organisation and stay.
This is the reason to have people join as themselves rather than sharing an account. When somebody leaves a shared login, the choice is to change a password everybody uses or to leave a former employee with access. Neither is a good choice, and both are avoidable.
What the organisation can see about itself
The activity figures cover the whole organisation rather than one person: listings published, views, saves and enquiries, with this month shown against the total. See performance for what each number is actually counting, which is less obvious than it looks.
Billing shows the plan, the API allowance and how much of this month's has been spent. Any member can see it. What the organisation has spent against its limit is not privileged information within the organisation, and a developer who cannot see the limit cannot tell why their calls started failing.
API keys
Keys belong to the organisation, not to the person who made one, so a key outlives its author's account.
They are a separate thing from membership, and the separation is deliberate: adding somebody to the team does not give them a key, and revoking a key does not remove anybody from the team. Key management is in the developer console, and what a key may do is decided by its scopes rather than by the role of whoever created it.
Revoke a key when the integration using it is retired, not only when somebody leaves. An unused key that still works is the one nobody notices being used.