Add blank authentication and user provisioning pages

[mintlify]

Adds three placeholder pages for content to be written manually:

• administration/authentication/single_sign_on.md — "Single Sign On", under Authentication & access
• administration/authentication/magic_link.md — "Magic Link", under Authentication & access
• administration/managing_users/automated_user_provisioning.md — "Automated User Provisioning", under Users & roles

Each page contains only its title. Extracted from #380 so this authentication work can proceed independently of the Kosli Capture page.

---

Generated by Mintlify Agent.

Requested by: graham@kosli.com via Slack
Mintlify session: slack_1782915660.508229_D0AM66349C1

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated (UTC)
kosli	🟢 Ready	View Preview	Sep 3, 2026, 8:26 AM

[claude]

Claude finished @FayeSGW's task in 1m 56s —— View job

---

Doc review

Reviewed at branch head (8f203d8). Findings already fixed by 67efbb4, f754db8, 3a6d284 and 8f203d8 are not repeated — that includes the unclosed <Steps> tag, the empty provisioning page, the missing descriptions, and the SCIM role-behaviour contradiction between automated_user_provisioning.md:55 and roles_in_kosli.md:191, which now say the same thing.

Four findings posted inline:

#	Location	Category
1	administration/authentication/magic_link.md:22	Improvement — "and ask you" → "asks", no terminating full stop
2	administration/authentication/magic_link.md:7	Improvement — "setup" as a verb
3	administration/authentication/single_sign_on.md:2-9	Improvement — Title Case headings, and three renderings of two feature names across the two new pages
4	administration/authentication/magic_link.md:15	Suggestion — <Step> elements have no title, unlike single_sign_on.md in this same PR

Two smaller points, not worth inline comments:

• No route from SSO to magic link. magic_link.md:7 links to the SSO page, but single_sign_on.md has no link back. An admin evaluating sign-in options lands on the SSO page first and has no way to discover magic link exists. One sentence in the intro would close the loop.
• Nav ordering (config/navigation.json:47-55). The two new pages cover human sign-in but are appended after three machine/API-auth pages, so "Authentication & access" now reads API-first. Raised earlier while the pages were empty; now that they have bodies, leading with SSO and magic link is a more defensible order. Entirely optional.

Links — all six internal targets in the changed files resolve (single_sign_on, automated_user_provisioning, roles_in_kosli), all eight referenced images exist under images/administration/, and no page was moved or renamed, so no config/redirects.json entry is needed. Both new pages are listed in config/navigation.json, and the group and Diátaxis placement look right for all three. I could not read gh pr checks for the link-rot result (command not permitted in this run), so treat the above as the only link verification.

3 Improvements, 1 Suggestion, 0 Critical. Nothing here blocks the merge; the two magic_link.md grammar fixes are the ones worth taking before it lands.
• branch docs/auth-pages

[claude]

Suggestion — ordering. The two new pages cover human sign-in, but they're appended after three machine/API-auth pages, so the group now reads API-first and buries the topic most admins land here looking for. Consider leading with human auth:

Suggested change

	"administration/authentication/api_authentication_methods",
	"administration/authentication/service_accounts",
	"administration/authentication/api_key_rotation"
	"administration/authentication/api_key_rotation",
	"administration/authentication/single_sign_on",
	"administration/authentication/magic_link"
	]
	"pages": [
	"administration/authentication/single_sign_on",
	"administration/authentication/magic_link",
	"administration/authentication/api_authentication_methods",
	"administration/authentication/service_accounts",
	"administration/authentication/api_key_rotation"
	]

Non-blocking — happy to leave as-is if you'd rather not reshuffle existing entries while the pages are still empty.

[claude]

Improvement — subject–verb disagreement and a missing full stop. "Kosli then sends you an email … and ask you to check your inbox" — should be "asks", and the sentence doesn't terminate.

Suggested change

	Kosli then sends you an email containing the link and ask you to check your inbox
	Kosli then sends you an email containing the link and asks you to check your inbox.

[claude]

Improvement — the two pages added in this PR name the feature differently. magic_link.md:7 links here as "[single sign-on]", so a reader clicks a link labelled single sign-on and lands on a page headed Single Sign On. The magic link page has the same split internally: Magic Link in the title and line 7, magic link in both ## headings and the body.

Pick one form per feature and use it in the title, headings and prose. Sentence case ("Single sign-on", "Magic link") is what CLAUDE.md asks for and what every sibling in this group uses (api_authentication_methods.md, service_accounts.md, api_key_rotation.md — all unquoted sentence case), and hyphenated "single sign-on" is the standard rendering.

There's also no route from here back to magic link, though this page is where an admin evaluating sign-in options will land first.

[claude]

Improvement — subject–verb disagreement, and the sentence doesn't terminate. "Kosli then sends you an email … and ask you" should be "asks", and there's no full stop.

Suggested change

	Kosli then sends you an email containing the link and ask you to check your inbox
	Kosli then sends you an email containing the link and asks you to check your inbox.

[claude]

Improvement — subject–verb disagreement, and the sentence has no full stop. "Kosli then sends you an email … and ask you to check your inbox" should be "asks". This is the only one of the three <Step> bodies on the page that doesn't terminate.

Suggested change

	Kosli then sends you an email containing the link and ask you to check your inbox
	Kosli then sends you an email containing the link and asks you to check your inbox.

[claude]

Improvement — "setup" is the noun; the verb is "set up".

Suggested change

	Magic Link is a way of signing into Kosli without needing to setup [single sign-on](/administration/authentication/single_sign_on). When you want to sign in, Kosli emails you a link, and clicking that link signs you in.
	Magic Link is a way of signing into Kosli without needing to set up [single sign-on](/administration/authentication/single_sign_on). When you want to sign in, Kosli emails you a link, and clicking that link signs you in.

[claude]

Improvement — the two pages added here still name their own features three different ways.

• This page: Single Sign On in the title, headings and body.
• magic_link.md:7 links here as "[single sign-on]", and automated_user_provisioning.md:16 links here as "[single sign-on]" too — so both inbound links are labelled differently from the page they land on.
• magic_link.md is split against itself: Magic Link in the title and line 7, magic link in both ## headings and lines 11/17.

CLAUDE.md asks for sentence case in headings, and every sibling in this group uses an unquoted sentence-case title (api_authentication_methods.md, service_accounts.md:2, api_key_rotation.md). "Single sign-on" is also the conventional rendering.

Suggested change

	title: Single Sign On
	title: Single sign-on

If you go with this, the ## Enabling Single Sign On heading (line 9) and line 7 need the same treatment, as does Magic Link → Magic link on the magic link page — pick one form per feature and use it in the title, headings, prose and link text.

[claude]

Suggestion — the <Step> elements have no title, unlike every other <Steps> block in administration/. single_sign_on.md:20-44 in this same PR titles all four of its steps, and service_accounts.md:15-28 titles all four of its. Without titles these render as bare numbers, so a reader scanning the page gets no summary of the flow.

Suggested change

	<Steps>
	<Steps>
	<Step>

The other two would be something like title="Check your inbox" and title="Click the link".

[claude]

Improvement — subject–verb disagreement, and the sentence has no full stop. "Kosli then sends you an email … and ask you to check your inbox" should be "asks". This is the only one of the three <Step> bodies that doesn't terminate.

Suggested change

	Kosli then sends you an email containing the link and ask you to check your inbox
	Kosli then sends you an email containing the link and asks you to check your inbox.

[claude]

Improvement — "setup" is the noun; the verb is "set up".

Suggested change

	Magic Link is a way of signing into Kosli without needing to setup [single sign-on](/administration/authentication/single_sign_on). When you want to sign in, Kosli emails you a link, and clicking that link signs you in.
	Magic Link is a way of signing into Kosli without needing to set up [single sign-on](/administration/authentication/single_sign_on). When you want to sign in, Kosli emails you a link, and clicking that link signs you in.

[claude]

Improvement — the headings here are Title Case, and the two new pages name their own features inconsistently.

CLAUDE.md asks for sentence case for all headings; every sibling in this group uses an unquoted sentence-case title (api_authentication_methods.md:2 "API authentication methods", service_accounts.md:2 "Service accounts", api_key_rotation.md:2 "API key rotation"). Here the title, ## Enabling Single Sign On, and the body all use "Single Sign On".

The inconsistency is also visible to a reader following links:

• magic_link.md:7 and automated_user_provisioning.md:16 both link here with the text "single sign-on", so the link label never matches the page they land on.
• magic_link.md is split against itself: Magic Link in the title and lines 7/17, magic link in both ## headings and line 11.

Pick one rendering per feature and use it in the title, headings, prose and inbound link text.

Suggested change

	title: Single Sign On
	description: "Learn about configuring Single Sign On with Kosli"
	icon: "key"
	---
	Kosli supports signing-in using your identity provider, via Single Sign On (SSO).
	## Enabling Single Sign On
	title: Single sign-on
	description: "Learn about configuring single sign-on with Kosli."
	icon: "key"
	---
	Kosli supports signing in using your identity provider, via single sign-on (SSO).
	## Enabling single sign-on

[claude]

Suggestion — these <Step> elements have no title, unlike every other <Steps> block in administration/. single_sign_on.md:20-44 in this same PR titles all four of its steps, and service_accounts.md:15-28 titles all four of its. Untitled steps render as bare numbers, so a reader scanning the page gets no summary of the flow — and the two pages added together are inconsistent with each other.

Suggested change

	<Steps>
	<Steps>
	<Step>

The other two would be something like title="Check your inbox" and title="Click the link".