Team and access
naulon keeps two rosters around your account, and they answer different questions. This page is about the first one — the people who help you run the account. If you're looking for the second — the people credited on an article, who get paid a share of what it earns — that's For authors, and it's a separate invite entirely.
Two rosters, not one
Your team is who has a role on the account itself: who can see billing, manage sites, invite other people, and so on. Your authors are who's credited on a given site's content and gets paid for it. They're stored separately, invited separately, and removed separately — taking someone off your team doesn't touch their author credit on a site, and taking someone off a site's author roster doesn't touch their team role. The same person can hold both at once — your co-founder might be an admin on the team and a credited author on three articles — but they're two rows, not one.
This page covers the team roster. For the author roster, see For authors.
Roles
| Role | What it can actually do |
|---|---|
| Owner | Everything, including the handful of things nobody else can do: delete a site, pay or manage the account's bill, request a plan change, run the account's data-subject requests (GDPR/CCPA export or erasure), and set the org's security policy — for example, requiring two-factor for everyone on the team. There's exactly one owner per account; it isn't a role you hand out, it's the account. |
| Admin | Nearly everything, day to day: create and edit sites and domains, configure credits and pricing, manage the team roster — invite, remove, change roles — manage API keys, webhooks and notification settings, and view billing and earnings across every site. The six things reserved for Owner above stay reserved; notably, Admin can't pay an invoice or change where a site's payouts go. |
| Billing manager | View and pay the account's invoices, and see the team roster. Nothing else — no sites, no credits, no inviting anyone. |
| Analyst | Read-only, but broad: every site, the team roster, billing, earnings across every site, and the audit log. Can run a data export. Can't change anything. |
| Developer | The technical-integration role: view sites, edit a site's credits configuration, manage API keys and webhooks. No visibility into billing, earnings, or the team roster. |
Author isn't in this table because it isn't assigned from here — it's its own roster, its own invite, and its own page (For authors).
Inviting someone
Owner and Admin can invite. Pick a role — Admin, Billing manager, Analyst, or Developer — and enter an email. The invite does nothing on its own: no access exists until the person you invited accepts it themselves.
How many teammates you can have depends on your plan — see /pricing. A pending invite takes a seat the moment you send it, not just once it's accepted, so re-sending to someone still pending doesn't cost you a second seat. And if the account has an open, unpaid invoice, inviting anyone new is refused until it's settled — see Billing and invoices — though nobody already on the team loses anything while that's true.
What the invitee sees. An email invites them to the account. Opening it and signing in — or setting up their account, if they're new — lands them on a page naming your account and the role you offered, matched against the exact address you invited. If they're signed into a different address, it won't match, and they need to sign in as the one the invite was actually sent to. Any invite waiting for them also shows up as a banner right at the top of their own Settings page, so they don't have to go hunting through their inbox a second time. Accepting makes the role real immediately; declining costs them nothing and the invite is simply gone. A link that's already been used, or one you've revoked, just says it isn't valid — deliberately the same message either way.
You can revoke a pending invite any time before it's accepted, from the same roster list.
Provisioning from your identity provider (SCIM)
If you'd rather your directory drive the roster than invite people by hand, naulon speaks SCIM. It's under Settings → Security, it works on every plan, and only the account owner can set it up — a SCIM token can rewrite your whole roster through a machine surface that checks no roles of its own, so minting one is deliberately as privileged as the other account-wide security switches.
Mint the token, hand it and the base URL to your provider, and map each of its groups to a role. A group may map to any role except Owner, including any custom role you've defined — your directory decides who's an employee, it never decides who owns the account.
The secret is shown exactly once, by the mint that creates it. Nothing afterwards can reveal it — not the settings page, not the audit log, which records a short preview instead. There is one live token per account, so minting again is how you rotate, and how you kill one that leaked.
The roster below the mapping shows who your provider has actually provisioned, pending rows included. A pending row is one your IdP considers done and that holds nothing yet: provisioning stages a membership, and it becomes real when that person first signs in and claims it under the address the directory sent.
Changing a role
Owner and Admin can change anyone else's role — except the owner's own row, which isn't editable through this screen. Changing a role replaces their access outright: whatever the old role granted is gone the moment the new one is set, not layered on top of it.
Removing a teammate
Owner and Admin can remove anyone but the owner. Removal takes their access away immediately, not just their name off the list — and if they'd been issued an agent token against the account's wallet, that's revoked in the same action, so a removed teammate can't keep spending against it after the fact.
Removing someone from the team roster is independent of the author roster: if they're also credited as an author on one of your sites, that credit and its payout wallet are untouched. Remove them there separately if that's what you mean to do — see For authors.