docs: correct the account provisioning setup instructions

[carolinaroncaglia]

Summary

The connector page told readers to put their New Relic authentication domain ID into "C1's create-account form". That form does not exist — the app's Accounts tab offers only Import from file. A reader who followed the page reached the end of the walkthrough holding a domain ID with nowhere to put it.

This replaces that section with the real path: C1 creates the account when a user requests access to the app, and the account details come from the app's provisioning mappings. The C1-side procedure already lives in Configure account provisioning, so the page links there rather than restating it, and adds only what is specific to this connector.

What changed

docs/connector.mdx

1. Authentication domain ID destination (measured) — removed both references to a create-account form. The section now ends by telling the reader to keep the ID for the mappings step.
2. New "Set up account provisioning mappings" section (measured) — documents the four mappings the connector's account-creation schema requires, and states what triggers account creation. The mapping names come from pkg/connector/users.go:194-201, which requires user_type and authentication_domain_id and errors without them.
3. Quoting and constants (measured) — user_type and authentication_domain_id are entered as quoted CEL string literals, and they are fixed values rather than expressions, so one app provisions into exactly one tier and one authentication domain. Neither fact was on the page, and both cost time during validation.
4. Frontmatter description (verified) — was the provisioning variant with its final clause missing. The connector declares CAPABILITY_ACCOUNT_PROVISIONING and CAPABILITY_RESOURCE_DELETE, so the full variant applies. description and og:description still match.

README.md

5. Data Model (verified) — listed only the four synced resource types. baton_capabilities.json also declares CAPABILITY_ACCOUNT_PROVISIONING, CAPABILITY_RESOURCE_DELETE, CAPABILITY_PROVISION on group and role, and CAPABILITY_ACTIONS. Added the write capabilities and the update_user action.
6. Command line usage (verified) — the embedded --help block listed 8 flags and 3 commands. The current binary reports 28 flags and 5 commands. Replaced with the real output.

Deliberately not changed

• The Roles row in the capabilities table. baton_capabilities.json declares CAPABILITY_PROVISION on role while the table shows Sync only. Role provisioning is not reachable from any C1 surface today and its dispatch rejects role scopes outside organization/account/group, so adding the checkmark would document a path a reader cannot take. Tracked separately.
• The "That's it!" completion lines. The docs voice guide says not to celebrate task completion; the connector-docs template's quality checklist requires both tabs to end with a completion message. Two shipped guides disagree, and resolving that is not this PR's job.
• docs/docs-info.md. This repo does not have one. It is an input written by the connector author, not something a docs correction should invent.

Verified correct while auditing — please do not "fix" these

• The connector actions section names the Perform connector action automation step. That is where update_user appears; the Account lifecycle action step offers zero options for this app.
• update_user's user_id is described as a resource reference. It is — passing a raw New Relic user ID fails with resource <id> with type user was not found.

Verified against the running connector on a sandbox tenant on 2026-08-26.

[linear-code]

CXH-2336

[github-actions]

🟡 Suggestion: "requires four mappings" overstates two of them. In pkg/connector/users.go:181-202, only user_type and authentication_domain_id are hard requirements — email falls back to accountInfo.GetLogin() and name falls back to the email. Consider "requires these four mappings" → something like "uses four mappings; user_type and authentication_domain_id are required" so a reader debugging a create account requires user_type error knows which two actually gate creation.

[github-actions]

Connector PR Review: docs: correct the account provisioning setup instructions

Blocking Issues: 0 | Suggestions: 1 | Threads Resolved: 0
Criteria: Criteria status: loaded .claude/skills/ci-review.md from trusted base 5e372e3c74f5.
Review mode: full
View review run

Review Summary

Scanned the full PR diff for security and correctness: it touches only README.md and docs/connector.mdx, with no Go, go.mod, or go.sum changes, so there is no runtime or dependency surface to break. I verified each factual claim against the checkout — the update_user argument schema matches pkg/connector/connector.go:98-136, the provisioning bullets match roles.go (org/account/group role scopes, groups-only principals), groups.go, and users.go CreateAccount/Delete, the capability list matches baton_capabilities.json, and --base-url is correctly absent from the --help block because pkg/config/config.go:18-23 marks it hidden. One documentation-accuracy suggestion below; nothing blocking.

Security Issues

None found.

Correctness Issues

None found.

Suggestions

• docs/connector.mdx:54 — "requires four mappings" overstates name and email, which have fallbacks in pkg/connector/users.go:181-202; only user_type and authentication_domain_id are hard requirements.

Prompt for AI agents

Verify each finding against the current code and only fix it if needed.

Suggestions:

In `docs/connector.mdx`:
- Around line 54: The sentence "The New Relic connector requires four mappings:" is
  stronger than the code. In pkg/connector/users.go CreateAccount, the `email` profile
  field falls back to accountInfo.GetLogin() and `name` falls back to the resolved email,
  so neither hard-fails. Only `user_type` and `authentication_domain_id` return an error
  when missing. Reword so the table still recommends all four mappings but marks
  `user_type` and `authentication_domain_id` as the required ones — for example
  "The New Relic connector uses four mappings; `user_type` and `authentication_domain_id`
  are required and account creation fails without them." This helps a reader who hits
  "create account requires user_type" find the right row.

[github-actions]

No blocking issues found.