Enterprise controls

Everything on this page is part of the Enterprise plan. See pricing for what's included at each tier. These controls live in the dashboard: single sign-on under Settings → Security, data subject requests under Settings → Data requests, reconciliation under Settlement, and scheduled exports/anomaly alerts under Automation.

Single sign-on (SAML)

Prove you control an email domain, then connect your identity provider to it. An organization can prove up to 10 domains and connects exactly one provider, which answers for all of them.

To prove a domain, add it under Settings → Security and we hand you a TXT record to publish. Until that record resolves, nobody can route sign-ins for the domain — that's what stops a stranger from claiming yourcompany.com before you do. Press Check DNS once it's live. The record stays required after verification, not just during setup: it's the ongoing proof that the domain is still yours, and if it disappears while another organization can prove control of the same domain, they can take over routing for it. We show the record permanently for exactly that reason, not just until it first resolves.

Once at least one domain is verified, connect your identity provider with its SAML metadata — a URL if it publishes one (Okta does), or the XML file directly (Entra ID and ADFS usually hand you a download instead of a URL, so both are accepted). The provider then answers for every domain you've verified at that point, and any domain you verify later is added to it automatically — you don't reconnect. Removing your last verified domain disconnects the provider too, since a SAML provider with nothing to answer for is unreachable.

Disconnecting the provider keeps your verified domains. That's deliberate: if you're moving from Okta to Entra ID, you reconnect with new metadata immediately, rather than republishing TXT records and waiting out DNS propagation for a change that never touched the domain itself.

Connecting or disconnecting SSO never touches an existing session — anyone already signed in stays signed in. SSO also doesn't replace password sign-in; it's a separate route (/login/sso, where someone enters their organization's domain) that exists alongside your normal login, not instead of it.

The first time someone signs in through your identity provider, they land on your organization's roster with no role. That split is intentional: your IdP decides who counts as an employee, but only your organization's owner decides what they're allowed to do here — a role has to be granted separately. If that person already had an account with you (a password signup from before you adopted SSO, or a pending invite under the same address), their existing membership row is re-pointed at the new SSO identity instead of a duplicate being created — but only when the address sits under a domain you've actually proven you control. Configuring any of this — claiming a domain, connecting or disconnecting a provider — is restricted to your organization's owner.

Data subject requests (GDPR/CCPA)

Under Settings → Data requests, identify a person by any single handle — their email, their user ID, or their author (contributor) ID — and either export everything held about them or erase their footprint in your organization. We cross-reference your team and contributor records from whichever handle you give us, so a request doesn't miss data sitting under a different handle for the same person (an email that was changed, for instance).

Export downloads a JSON package: organization memberships, contributor memberships, role grants, the tenants they own, their scheduled exports and anomaly alerts, gating decisions logged against them within your tenants, and the audit events where they were the actor — all scoped to your organization. It's read-only and carries no confirmation gate.

Erasure is destructive and gated by typing the identifying handle back to confirm, the same pattern GitHub uses for a destructive repository action. It removes their non-owner organization memberships, contributor memberships, role grants, and the gating decisions logged against them in your tenants — plus their scheduled exports and anomaly alerts, but only if they don't own tenants outside your organization too. Those two are stored with no per-organization split, so if the same person owns sites in another organization as well, we leave that automation alone rather than reach into data that isn't yours to erase, and the response tells you so.

Four things are never erased, regardless of scope: the audit trail (retained as the accountability record under legal obligation), financial and settlement records (they're wallet-keyed rather than person-keyed, and retained for accounting and tax purposes), gating decisions that aren't tied to one of your tenants (kept as an operational/security log — the ones tied to your tenants above are erased normally), and the login account itself. That last point matters for how to read the whole feature: this is a scoped erasure of the person's relationship with your organization, not a closure of their naulon account everywhere they might have one.

Every export and erasure is itself recorded in your audit log the moment it runs, and an erasure's own audit row never carries the erased person's personal data — only counts of what was removed. There's no ticket or review queue: identify the subject, and export or (after confirming) erase runs immediately.

Reconciliation

Under Settlement → Reconciliation. The earnings you see elsewhere in the dashboard are the author's cut of a paid citation, which settles the moment the read is paid for. Reconciliation is about the other legs of that same payment — an operator fee, or a co-author cut — which are quoted at the same moment but settle separately, on a drain. It buckets those legs by state: settled, outstanding (still inside its authorization window, in flight), and expired (the window passed unsettled, meaning the buyer was never charged at all — uncollected revenue, not a debt anyone owes you). "Books balanced" means zero outstanding and zero expired.

Worth being precise about the boundary here: reconciliation checks naulon's own recorded settlement state against its own ledger. It isn't a live lookup against the chain — "settled" means our own drain marked the leg handed off exactly once, not that we re-confirmed it on-chain at the moment you loaded the page.

The audit log

The Activity log page is the compliance trail of authenticated actions across your organization's control plane: who changed a config, invited or removed a teammate, deleted a site, connected an identity provider, and so on. Visibility is organization-wide by design — anyone with access to the page sees every member's actions, not only their own, which is what makes it usable as an accountability record rather than a personal history.

It exports as CSV (every column, meant for an auditor to work with directly) or PDF (a readable filing copy, capped at 1,000 rows with an honest note when it's clipped and a pointer to the CSV for the rest). The trail is append-only — nothing in it is ever edited, only aged out once your plan's retention period allows it. On Enterprise, retention is unlimited, so the trail is kept indefinitely rather than pruned.

Automation: scheduled exports and anomaly alerts

Two independent registers on the Automation page.

A scheduled export delivers either the CSV earnings export or the PDF payout statements by email, on a daily, weekly, or monthly cadence, scoped to all your sites or just one. Each delivery covers a trailing window you choose independently of the cadence — you could, for example, get a weekly email covering the trailing 30 days.

An anomaly alert fires on one of three conditions, evaluated over a window you set (from the last 24 hours out to lifetime): earnings below a dollar threshold, zero earnings at all, or denied requests above a count. Once a condition breaches, the alert throttles to firing at most once per window length, so a standing problem doesn't send you the same alert on every check.

A scheduled export always arrives by email with its file attached. An anomaly alert also arrives by email, and separately fires the anomaly.detected webhook event if you have an endpoint configured for it — see Webhooks for what that payload carries and how to verify it. Webhooks are free on every plan; the alert and export rules that can trigger them are the Enterprise-gated part.