Document organization-managed users and fix adjacent identity gaps

[jkodroff]

Adds a concepts page for organization-managed Pulumi Cloud accounts — accounts an organization creates and controls through SAML JIT provisioning or SCIM — and closes the seven adjacent documentation gaps found in the same investigation.

Changes

New page — concepts/org-managed-users.md: how an account becomes org-managed, why an administrator wants it, how it differs from SAML organization membership, the three restrictions, and the destructive Migrate to Org-Managed Account migration. Cross-linked from Accounts, SAML, SCIM, and SAML admin.

Adjacent fixes

• FAQ: the answer on linking an existing account conflated linking an OAuth identity with signing in through it — now split by provider kind
• Accounts: new "If the identity options aren't there" section
• Organizations: Bitbucket workspace admin requirement; backing membership vs. Pulumi membership; destructive SAML disconnect; multi-org prerequisite for SAML conversion; Atlassian/Bitbucket naming; trimmed the roles table that duplicated RBAC
• SCIM: provisioned users are org-managed; identity-provider change revokes the SCIM token
• New saml-conversion-prereq shortcode, used in all six SAML guides

Concepts nav weights shifted to seat the new page after Accounts.

Fixes #21103

[unblocked]

✅ No issues found

About Unblocked

Unblocked has been set up to automatically review your team's pull requests to identify genuine bugs and issues.

📖 Documentation — Learn more in our docs.

💬 Ask questions — Mention @unblocked to request a review or summary, or ask follow-up questions.

👍 Give feedback — React to comments with 👍 or 👎 to help us improve.

⚙️ Customize — Adjust settings in your preferences.

[github-actions]

Pre-merge Review — Last updated 2026-08-25T00:55:54Z

Tip

Summary: This PR adds a new concept page, content/docs/administration/concepts/org-managed-users.md, that defines what an organization-managed Pulumi Cloud account is, how SAML sign-in / SCIM / manual migration create one, and the three restrictions that follow — and then closes the adjacent gaps that page exposes across accounts.md, organizations.md, the SAML guides, the SCIM guide, and the Pulumi Cloud FAQ. It parallels the existing sibling concept pages (accounts.md, agent-accounts.md, billing-managers.md) in shape and frontmatter, and slots in at menu weight 3 with the six pages below it shifted down one. The wrongness that would actually hurt a reader here is a wrong irreversibility boundary or a wrong UI label on the migration flow: migration is described as permanent and destructive, so a reader who follows it on a mistaken premise loses organization membership and every linked identity with no undo. Passes run: Hugo build + link-integrity preflight (clean, one page added to the sitemap, no broken links), frontmatter alias/URL/menu-parent validation (clean), menu-weight collision check across all 8 sibling concept pages, anchor resolution for every new internal link, external claim verification (97 claims), a coherence readthrough of the new page, and pattern-based prose linting (no findings).

Review confidence:

Dimension	Level	Notes
mechanics	HIGH	Build, links, anchors, aliases, and the menu-weight renumbering across all 9 concept pages all check out.
facts	MEDIUM	The load-bearing product behaviors on the new page — what migration destroys, when it takes effect, the exact Migrate to Org-Managed Account label, and the multi-organization carve-out — have no public source to check against. They need an author or engineering confirmation.
coherence	HIGH	The new page reads cleanly and the surrounding edits point at it consistently.
cross-sibling consistency	MEDIUM	All 8 sibling concept pages read; one duplicated prerequisite paragraph found (below), otherwise consistent.

Investigation log

• Cross-sibling reads: 8 of 8 siblings
• External claim verification: 61 of 97 claims verified (11 unverifiable, 0 contradicted) · 4 specialists (numerical, cross-reference, capability, framing); 0 cross-specialist corroborations · routed: 0 inline, 78 Pass 1, 3 Pass 2 (verified 2, contradicted 0, unverifiable 1), 16 Pass 3 (verified 9, contradicted 0, unverifiable 7).
• Cited-claim spot-checks: 3 of 3 cited claims fetched and compared
• Frontmatter sweep: ran on body + meta_desc
• Temporal-trigger sweep: ran (recency words present in diff; spot-check in-review)
• Code execution: not run (no static/programs/ change)
• Code-examples checks: not run (no fenced code blocks in content files)
• Editorial-balance pass: not run (not under content/blog/)

🚨 Outstanding	⚠️ Low-confidence	💡 Pre-existing	✅ Resolved
1	8	1	0

🔍 Verification trail

97 claims extracted · 61 verified · 11 unverifiable · 0 contradicted

• L22 in content/docs/administration/concepts/_index.md "Pulumi provides a documentation page at /docs/administration/concepts/org-managed-users/ about organization-managed users." → ✅ verified (evidence: PR Document organization-managed users and fix adjacent identity gaps #21110 ("Document organization-managed users and fix adjacent identity gaps") adds a new file content/docs/administration/concepts/org-managed-users.md in the same changeset as the linking _index.md edit, which will render at…; source: gh pr diff 21110 -R pulumi/docs)
• L71 in content/docs/administration/concepts/accounts.md "There exists a documentation section titled 'Backing membership doesn't grant Pulumi membership' at /docs/administration/concepts/organizations/#backing-member…" → ✅ verified (evidence: content/docs/administration/concepts/organizations.md line 66 contains: ### Backing membership doesn't grant Pulumi membership {#backing-membership}, confirming both the heading title and the anchor #backing-membership.; source: repo:content/docs/administration/concepts/organizations.md)
• L73-78 in content/docs/administration/concepts/accounts.md "There are exactly two things that can remove the identity-connection controls from a Pulumi account: the account being organization-managed, or the identity…" → ➖ not-a-claim (evidence: The claim is a direct restatement of the file's own text: "The controls for connecting identities aren't available to every account. Two things remove them: * Your account is organization-managed... * The provider isn't configured for…; source: repo:content/docs/administration/concepts/accounts.md)
• L77-78 in content/docs/administration/concepts/accounts.md "There exists a documentation page titled 'Organization-managed users' at /docs/administration/concepts/org-managed-users/." → ✅ verified (evidence: The file content/docs/administration/concepts/org-managed-users.md exists with front matter title: Organization-Managed Users, confirming the linked page at /docs/administration/concepts/org-managed-users/ exists as claimed.; source: repo:content/docs/administration/concepts/org-managed-users.md)
• L78 in content/docs/administration/concepts/accounts.md "In self-hosted Pulumi Cloud, an identity provider only appears as a connection option if the deployment has been configured with OAuth credentials for that…" → ✅ verified (framing: Source documents env vars enabling signin for GitHub/GitLab/Bitbucket OAuth specifically; claim generalizes to "an identity provider" which is the general…; evidence: The self-hosting console component docs (content/docs/administration/self-hosting/components/console.md) list per-provider OAuth env vars required to enable each identity provider: "GITHUB_OAUTH_ID | GitHub OAuth app client ID. Used for…; source: repo:content/docs/administration/self-hosting/components/console.md)
• L9 in content/docs/administration/concepts/customer-managed-keys.md "The Customer Managed Keys page has a navigation menu weight of 9 within the administration-concepts section." → ✅ verified (evidence: (escalated from pass3) The file's front matter shows: menu:\n administration:\n parent: administration-concepts\n weight: 9\n identifier: administration-concepts-customer-managed-keys, confirming a weight of 9 within the…; source: repo:content/docs/administration/concepts/customer-managed-keys.md)
• L20-22 in content/docs/administration/concepts/customer-managed-keys.md "Pulumi Cloud supports Customer Managed Keys (CMKs), which allow customers to use their own encryption keys via an external Key Management System (KMS) to…" → ✅ verified (framing: The claim states the general capability (CMKs via external KMS); the file itself and sibling pages narrow this to currently ESC-only/AWS-KMS-only, which is a…; evidence: Sibling page content/docs/administration/concepts/_index.md independently describes the same feature: "Customer managed keys — using your own encryption keys to protect data at rest, currently for Pulumi ESC with AWS KMS," and the blog…; source: gh search code --owner pulumi "customer-managed-keys" (content/docs/administration/concepts/_index.md, content/blog/bring-your-own-keys-with-pulumi-esc/index.md))
• L24-26 in content/docs/administration/concepts/customer-managed-keys.md "When a customer adds their first CMK in Pulumi Cloud, all existing data keys encrypted with the Pulumi-managed key are automatically re-encrypted with the…" → ✅ verified (evidence: (escalated from pass1) Official Pulumi docs state: "When you add your first CMK, all existing data keys encrypted with the Pulumi-managed key will be automatically re-encrypted with the new CMK." This matches the claim's assertion exactly.; source: https://www.pulumi.com/docs/administration/security-compliance/customer-managed-keys/)
• L24-26 in content/docs/administration/concepts/customer-managed-keys.md "When a customer adds their first CMK, all existing data keys encrypted with the Pulumi-managed key are automatically re-encrypted with the new CMK." → ✅ verified (evidence: (escalated from pass1) The official Pulumi docs page states: "When the first Customer Managed Key is added, all data keys encrypted with the Pulumi-managed key will be automatically re-encrypted with the new Customer Managed Key,"…; source: https://www.pulumi.com/docs/administration/security-compliance/customer-managed-keys/)
• L28 in content/docs/administration/concepts/customer-managed-keys.md "Only organization admins can manage Customer Managed Keys in Pulumi Cloud." → 🤷 unverifiable (evidence: The claim restates the reviewed file's own text ("Only organization admins can manage CMKs.") and no independent RBAC/product source could be located to corroborate the access-control restriction; the reviewed file cannot verify itself.; source: content/docs/administration/concepts/customer-managed-keys.md)
• L31-34 in content/docs/administration/concepts/customer-managed-keys.md "Pulumi is working on expanding Customer Managed Keys encryption support to additional Pulumi products beyond Pulumi ESC." → ➖ not-a-claim (evidence: The doc itself states: "Currently, Customer Managed Keys are only used to encrypt data in Pulumi ESC... We are working on adding support for more KMS providers and expanding encryption to additional Pulumi products." The claim is a…; source: repo:content/docs/administration/concepts/customer-managed-keys.md)
• L33-34 in content/docs/administration/concepts/customer-managed-keys.md "Pulumi is working on adding support for more KMS providers and expanding CMK encryption to additional Pulumi products." → ➖ not-a-claim (evidence: The claim is a paraphrase of the doc's own in-page note: "We are working on adding support for more KMS providers and expanding encryption to additional Pulumi products." This is Pulumi describing its own roadmap/intent in its own…; source: content/docs/administration/concepts/customer-managed-keys.md)
• L41-43 in content/docs/administration/concepts/customer-managed-keys.md "To view Customer Managed Keys, an admin must expand the organization's Settings menu, select Organization, then select the Customer Managed Keys tab." → ➖ not-a-claim (evidence: The claim text is a direct paraphrase of the file's own "Viewing Customer Managed Keys" section ("1. As an admin, expand the organization's Settings menu. 1. Select Organization. 1. Select the Customer Managed Keys tab."). It restates…; source: repo:content/docs/administration/concepts/customer-managed-keys.md)
• L45-54 in content/docs/administration/concepts/customer-managed-keys.md "All new data keys responsible for encrypting data created by an organization in Pulumi Cloud will be encrypted with the organization's default Customer…" → ✅ verified (evidence: (escalated from pass1) Pulumi's official Customer Managed Keys docs state: "All new data keys responsible for encrypting data created by your organization will be encrypted with this key" (referring to the default CMK), which is an exact…; source: https://www.pulumi.com/docs/administration/security-compliance/customer-managed-keys/)
• L49-50 in content/docs/administration/concepts/customer-managed-keys.md "All new data keys responsible for encrypting data created by an organization will be encrypted with the default key." → ➖ not-a-claim (evidence: The line is a direct paraphrase of the doc's own UI-field description: "Default: Indicates if the key is the default encryption key for the organization. All new data keys responsible for encrypting data created by your organization will…; source: repo:content/docs/administration/concepts/customer-managed-keys.md)
• L58 in content/docs/administration/concepts/customer-managed-keys.md "Adding a Customer Managed Key in Pulumi Cloud enables customers to use their own encryption key to protect sensitive data." → ➖ not-a-claim (evidence: The claim is a near-verbatim restatement of the doc's own text: "Adding a Customer Managed Key enables you to use your own encryption key to protect sensitive data in Pulumi Cloud." This is the file describing its own feature, not a…; source: content/docs/administration/concepts/customer-managed-keys.md)
• L61-62 in content/docs/administration/concepts/customer-managed-keys.md "When the first Customer Managed Key is added in Pulumi Cloud, all data keys encrypted with the Pulumi-managed key are automatically re-encrypted with the new…" → 🤝 matches (evidence: The claim is restated verbatim from the same doc's Overview section: "When you add your first CMK, all existing data keys encrypted with the Pulumi-managed key will be automatically re-encrypted with the new CMK. The encrypted data…; source: content/docs/administration/concepts/customer-managed-keys.md lines 24-26 and 61-62)
• L67-73 in content/docs/administration/concepts/customer-managed-keys.md "Adding an AWS KMS Customer Managed Key requires navigating to the Customer Managed Keys settings page in Pulumi Cloud, clicking 'Add Customer Managed Key'…" → ➖ not-a-claim (evidence: The claim is a verbatim paraphrase of the doc's own numbered steps (lines 69-73): "Go to the Customer Managed Keys settings page...Click Add Customer Managed Key...Enter a unique name...Provide the Role ARN...Provide the Key ARN". This…; source: repo:content/docs/administration/concepts/customer-managed-keys.md)
• L77-78 in content/docs/administration/concepts/customer-managed-keys.md "Disabling a Customer Managed Key in Pulumi Cloud prevents it from being used to create new data keys, but existing data keys remain encrypted with that key…" → ✅ verified (evidence: (escalated from pass1) Pulumi's official Customer Managed Keys doc states verbatim: "Disabling a key prevents it from being used to create new data keys, but existing data keys remain encrypted with the key until they are re-encrypted."; source: https://www.pulumi.com/docs/administration/security-compliance/customer-managed-keys/)
• L80 in content/docs/administration/concepts/customer-managed-keys.md "Disabling a Customer Managed Key is not available for default keys or keys undergoing re-encryption in Pulumi Cloud." → ✅ verified (evidence: The same doc states twice, consistently: "Disable: A button to disable the key. This option is unavailable for default keys or keys undergoing re-encryption." (L53-54) and "Disabling a key is not available for default keys or keys…; source: repo:content/docs/administration/concepts/customer-managed-keys.md)
• L84-88 in content/docs/administration/concepts/customer-managed-keys.md "To disable a Customer Managed Key in Pulumi Cloud, a user clicks the three-dot menu next to the key, selects Disable, chooses a re-encryption key, and clicks…" → ➖ not-a-claim (evidence: The claim is a verbatim paraphrase of the doc's own numbered steps: "1. Click the three-dot menu next to the key you want to disable. 2. Select Disable. 3. Choose a re-encryption key... 4. Click Disable to confirm." This is the author's…; source: repo:content/docs/administration/concepts/customer-managed-keys.md L82-88)
• L88 in content/docs/administration/concepts/customer-managed-keys.md "After disabling a key, a banner appears showing the re-encryption process status, and it disappears once the process is complete." → ✅ verified (evidence: (escalated from pass1) The Pulumi Cloud docs page on Customer Managed Keys states: "A banner will appear, showing the re-encryption process status." and "It disappears once the process is complete." This exactly matches the claim.; source: https://www.pulumi.com/docs/administration/security-compliance/customer-managed-keys/)
• L92-93 in content/docs/administration/concepts/customer-managed-keys.md "Disabling all Customer Managed Keys in Pulumi Cloud prevents them from being used to create new data keys, but existing data keys remain encrypted with those…" → ➖ not-a-claim (evidence: The claim verbatim restates the doc's own "Disabling All Customer Managed Keys" section: "Disabling all keys prevents them from being used to create new data keys, but existing data keys remain encrypted with the keys until they are…; source: repo:content/docs/administration/concepts/customer-managed-keys.md)
• L93 in content/docs/administration/concepts/customer-managed-keys.md "All data keys will be re-encrypted with the Pulumi-managed key when all Customer Managed Keys are disabled." → ✅ verified (evidence: Doc line 93 states: "Disabling all keys prevents them from being used to create new data keys, but existing data keys remain encrypted with the keys until they are re-encrypted. All data keys will be re-encrypted with the Pulumi-managed…; source: repo:content/docs/administration/concepts/customer-managed-keys.md (lines 90-93))
• L97-100 in content/docs/administration/concepts/customer-managed-keys.md "To disable all Customer Managed Keys, a user clicks the wheel button in the top right corner, clicks 'Disable all Customer Managed Keys', confirms the…" → ➖ not-a-claim (evidence: The claim is a verbatim restatement of the file's own numbered instructions (lines 97-100: 'Click on the wheel button...', 'Click Disable all Customer Managed Keys', 'Confirm the re-encryption process...', 'Click Disable all to…; source: repo:content/docs/administration/concepts/customer-managed-keys.md)
• L100 in content/docs/administration/concepts/customer-managed-keys.md "After disabling all keys, a banner appears showing the re-encryption process status, and it disappears once the process is complete." → ➖ not-a-claim (evidence: The doc itself states in step 5 of "Disabling All Customer Managed Keys": "A banner will appear, showing the re-encryption process status. It disappears once the process is complete." This is the PR's own documentation describing the…; source: repo:content/docs/administration/concepts/customer-managed-keys.md)
• L3 in content/docs/administration/concepts/org-managed-users.md "An organization-managed Pulumi Cloud account is created by SAML or SCIM and has restrictions applied to it." → ➖ not-a-claim (evidence: Line 3 is the page's own meta_desc summarizing its own content ("What an organization-managed Pulumi Cloud account is, how SAML and SCIM create one, and the restrictions that apply to it"); the body further clarifies a third path (manual…; source: repo:content/docs/administration/concepts/org-managed-users.md)
• L14 in content/docs/administration/concepts/org-managed-users.md "The organization's identity provider creates the organization-managed account and remains the source of truth for it." → ✅ verified (evidence: The doc's own body explains the mechanism this summary sentence restates: "Signing in to a SAML organization for the first time... Pulumi creates one for you" and "SCIM provisioning... provisions accounts from its identity provider.…; source: repo:content/docs/administration/concepts/org-managed-users.md)
• L14 in content/docs/administration/concepts/org-managed-users.md "An organization-managed user is a Pulumi Cloud account that belongs to an organization rather than to an individual." → ✅ verified (evidence: The claim is the page's own introductory definition, and it is internally consistent with the rest of the document, which explains org-managed accounts are created and controlled by an organization's identity provider (via SAML or SCIM)…; source: repo:content/docs/administration/concepts/org-managed-users.md)
• L16 in content/docs/administration/concepts/org-managed-users.md "Organization-managed accounts are created, updated, and deactivated from the organization's identity provider." → ✅ verified (evidence: The SCIM guide confirms: "User provisioning | Yes (create, read, update, and search)" and "Deprovisioning sets active to false, which removes the user's access to the organization" — i.e., accounts are created, updated, and…; source: content/docs/administration/guides/scim/_index.md)
• L16 in content/docs/administration/concepts/org-managed-users.md "Deprovisioning a user in the identity provider revokes that user's Pulumi access." → ✅ verified (framing: SCIM guide specifies the mechanism (active=false, org-level access removal, reversible); claim states the general behavioral outcome ("revokes Pulumi…; evidence: The sibling SCIM guide (content/docs/administration/guides/scim/_index.md) independently confirms this: "Deprovisioning sets active to false, which removes the user's access to the organization while preserving their account and its…; source: repo:content/docs/administration/guides/scim/_index.md)
• L16 in content/docs/administration/concepts/org-managed-users.md "An organization-managed account cannot be used to create organizations outside the managing organization's billing and governance." → 🤝 matches (evidence: The sibling page content/docs/administration/concepts/organizations.md independently states: "Organization-managed users can't create organizations. If an organization created your account through SAML or SCIM, the option isn't available…; source: content/docs/administration/concepts/organizations.md (sibling page, line ~44-46))
• L20 in content/docs/administration/concepts/org-managed-users.md "An account becomes organization-managed in exactly one of three ways: signing in to a SAML organization for the first time, SCIM provisioning, or migrating…" → ➖ not-a-claim (evidence: The claim is a verbatim paraphrase of the document's own section: "An account becomes organization-managed in one of three ways: Signing in to a SAML organization for the first time... SCIM provisioning... Migrating an existing account."…; source: repo:content/docs/administration/concepts/org-managed-users.md)
• L20-24 in content/docs/administration/concepts/org-managed-users.md "An account becomes organization-managed in exactly one of three ways: signing in to a SAML organization for the first time with no prior Pulumi account, SCIM…" (also L47) → ✅ verified (evidence: The linked SAML guide page corroborates the first mechanism verbatim: "Signing in through SSO without an existing Pulumi account creates one, and the organization manages that account... An account that already existed and later connects…; source: content/docs/administration/guides/saml/_index.md)
• L24 in content/docs/administration/concepts/org-managed-users.md "Migrating an existing account to organization-managed status is destructive." → ➖ not-a-claim (evidence: This is a faithful restatement of the document's own described product behavior: the same page states "Migrating an ordinary account to an organization-managed one is permanent and destructive, and it takes effect immediately," with a…; source: repo:content/docs/administration/concepts/org-managed-users.md)
• L28 in content/docs/administration/concepts/org-managed-users.md "Members of SAML organizations, whether organization-managed or not, sign in through the same identity provider." → ✅ verified (evidence: The sibling SAML guide confirms both account types authenticate via the same org SAML SSO: "If you're a member of a SAML-based Pulumi organization, you can sign in to your account via Single Sign-On... An account that already existed and…; source: repo:content/docs/administration/guides/saml/_index.md)
• L28 in content/docs/administration/concepts/org-managed-users.md "Belonging to a SAML-backed organization does not by itself make a Pulumi account organization-managed." → 🤝 matches (evidence: Sibling page content/docs/administration/guides/saml/_index.md states: "Signing in through SSO without an existing Pulumi account creates one, and the organization manages that account... An account that already existed and later…; source: repo:content/docs/administration/guides/saml/_index.md (L36))
• L32 in content/docs/administration/concepts/org-managed-users.md "An account is organization-managed if the organization created it, either because the user signed in through the organization's SAML SSO with no prior Pulumi…" → ➖ not-a-claim (evidence: The line is a table-row restatement of the page's own preceding definition ("An account becomes organization-managed in one of three ways: Signing in to a SAML organization for the first time... SCIM provisioning...") — it's the author's…; source: repo:content/docs/administration/concepts/org-managed-users.md)
• L32-33 in content/docs/administration/concepts/org-managed-users.md "An account is organization-managed if the organization created it (the user signed in through the organization's SAML SSO with no prior Pulumi account, or…" → ✅ verified (evidence: The org-managed-users.md page itself states this table (organization-created accounts via SAML-first-signin or SCIM are org-managed; user-created accounts that later connect SAML or accept an invite are not), and the cited anchor section…; source: content/docs/administration/guides/saml/_index.md#connect-saml-sso-to-an-existing-account)
• L35 in content/docs/administration/concepts/org-managed-users.md "An ordinary account that joins a SAML organization retains all capabilities of an ordinary account: it can still belong to other organizations, connect other…" → 🤷 unverifiable (evidence: The claim restates internal page logic: the doc's own "Restrictions" section states an organization-managed user "is subject to three restrictions that an ordinary Pulumi account isn't" (org membership limits, no additional identities…; source: repo:content/docs/administration/concepts/org-managed-users.md)
• L39 in content/docs/administration/concepts/org-managed-users.md "An organization-managed user is subject to exactly three restrictions that an ordinary Pulumi account is not subject to." → ➖ not-a-claim (evidence: (escalated from pass3) The document itself states "An organization-managed user is subject to three restrictions that an ordinary Pulumi account isn't" and then lists exactly three bulleted restrictions (Organization membership…; source: repo:content/docs/administration/concepts/org-managed-users.md)
• L39-43 in content/docs/administration/concepts/org-managed-users.md "An organization-managed user is subject to exactly three restrictions that an ordinary Pulumi account is not subject to: limits on organization membership…" → ✅ verified (evidence: org-managed-users.md's "Restrictions" section states "An organization-managed user is subject to three restrictions that an ordinary Pulumi account isn't:" followed by exactly three bullets: Organization membership, Additional…; source: repo:content/docs/administration/concepts/org-managed-users.md and repo:content/docs/administration/concepts/accounts.md#adding-new-identities)
• L41 in content/docs/administration/concepts/org-managed-users.md "An organization-managed account can belong to the organization that manages it and to organizations related to it as part of a multi-organization arrangement." → 🤷 unverifiable (evidence: (escalated from pass1) Web search did not surface Pulumi's org-managed-users documentation describing multi-organization membership arrangements for organization-managed accounts; this is a specific Pulumi Cloud product behavior claim…; source: WebSearch ran query "Pulumi organization-managed users multi-organization arrangement"; top results didn't address the claim)
• L41 in content/docs/administration/concepts/org-managed-users.md "A user who needs access to an unrelated Pulumi organization must create a separate Pulumi account that isn't organization-managed." → ✅ verified (evidence: The sibling SAML guide page independently corroborates this restriction: "Signing in through SSO without an existing Pulumi account creates one, and the organization manages that account: it can't join unrelated organizations, connect…; source: content/docs/administration/guides/saml/_index.md (sibling page), cross-referenced with content/docs/administration/concepts/org-managed-users.md)
• L47 in content/docs/administration/concepts/org-managed-users.md "Migrating an ordinary account to an organization-managed one takes effect immediately." → 🤷 unverifiable (evidence: (escalated from pass1) Web search did not surface Pulumi documentation specifically describing the "org-managed users" account migration process or its immediacy; this describes internal Pulumi Cloud account-management behavior that a…; source: WebSearch ran query "Pulumi org-managed users migrating account takes effect immediately"; top results didn't address the claim)
• L50 in content/docs/administration/concepts/org-managed-users.md "Migrating an account removes it from every organization other than the organization taking it over and that organization's related organizations." → ➖ not-a-claim (evidence: This line is a near-verbatim paraphrase of the warning box in the same document ("Migrating an account removes it from every organization other than the one taking it over and that organization's related organizations..."). It describes…; source: repo:content/docs/administration/concepts/org-managed-users.md)
• L50 in content/docs/administration/concepts/org-managed-users.md "After migration, any authentication method that depended on a deleted identity, such as GitHub or Google, stops working." → ✅ verified (evidence: The doc states migration "deletes every linked identity except the managing organization's SAML identity. Any authentication method that depended on a deleted identity, such as GitHub or Google, stops working." This is corroborated by…; source: content/docs/administration/concepts/org-managed-users.md (L50); content/docs/administration/concepts/accounts.md)
• L50 in content/docs/administration/concepts/org-managed-users.md "After migration, single sign-on through the managing organization becomes the account's only authentication method." → ➖ not-a-claim (evidence: The claim text is a verbatim restatement of the document's own sentence: "Single sign-on through the managing organization becomes the account's only authentication method." This is the PR's own authored content describing its own…; source: content/docs/administration/concepts/org-managed-users.md)
• L55-57 in content/docs/administration/concepts/org-managed-users.md "Before migrating, a user should transfer any stacks they want to keep out of the organizations they're about to leave, confirm they don't hold an admin role…" → ✅ verified (evidence: The org-managed-users.md page's "Before you migrate" list (lines 55-57) reads: "1. Transfer any stacks you want to keep out of the organizations you're about to leave.…; source: repo:content/docs/administration/concepts/org-managed-users.md (L53-57); repo:content/docs/administration/concepts/organizations.md (L125-131))
• L61-62 in content/docs/administration/concepts/org-managed-users.md "To migrate an account, a user navigates to Account settings and, under their email address, selects 'Migrate to Org-Managed Account'." → 🤷 unverifiable (evidence: (escalated from pass1) Pulumi's docs confirm the general UI pattern of "Account settings" with options listed "under your email address" (e.g., resend verification email), but no public source explicitly confirms a "Migrate to…; source: WebSearch ran query "Pulumi org-managed-users migrate personal account to organization managed"; top results didn't address the specific claim; intuition: This describes a specific Pulumi Cloud UI button/label that only Pulumi's own app source or internal design docs…)
• L64 in content/docs/administration/concepts/org-managed-users.md "A SAML admin keeps an alternative login method for as long as they hold the SAML admin role, and loses that alternative login method when the role passes to…" → ✅ verified (evidence: The cited SAML admin page states: "A SAML admin can log in to your Pulumi organization using an alternative login method," and "When a user stops being a SAML admin, they will automatically lose all other login methods." This directly…; source: content/docs/administration/guides/saml/saml-admin.md)
• L68-71 in content/docs/administration/concepts/org-managed-users.md "- Organizations" → ✅ verified (evidence: The repo contains content/docs/administration/concepts/organizations.md as a sibling file to org-managed-users.md, so the link /docs/administration/concepts/organizations/ resolves to a real, existing page.; source: gh api repos/pulumi/docs/contents/content/docs/administration/concepts)
• L44-46 in content/docs/administration/concepts/organizations.md "If an organization created a user's account through SAML or SCIM, the option to create an organization isn't available to that user." → ✅ verified (evidence: The org-managed-users doc explicitly states org-managed accounts (created via SAML sign-in or SCIM provisioning) are restricted from "Creating organizations," and the organizations.md source text itself reads: "If an organization created…; source: content/docs/administration/concepts/org-managed-users.md)
• L66-72 in content/docs/administration/concepts/organizations.md "Once a user connects the matching identity to their Pulumi account, they appear on the list of people a Pulumi organization admin can invite or add, but they…" → ✅ verified (evidence: The same doc page states: "Once you connect the matching identity to your Pulumi account, you appear on the list of people a Pulumi organization admin can invite or add. Until an admin does that, you have no access." This matches the…; source: content/docs/administration/concepts/organizations.md L66-72)
• L70 in content/docs/administration/concepts/organizations.md "Once a user connects the matching identity to their Pulumi account, they appear on the list of people a Pulumi organization admin can invite or add." → ➖ not-a-claim (evidence: The claim text is a near-verbatim restatement of the doc's own line 70: "Once you connect the matching identity to your Pulumi account, you appear on the list of people a Pulumi organization admin can invite or add." This is the reviewed…; source: repo:content/docs/administration/concepts/organizations.md)
• L99 in content/docs/administration/concepts/organizations.md "The Pulumi documentation page at /docs/administration/concepts/billing-managers/ describes delegating billing access without admin rights via Billing Managers." → ✅ verified (evidence: The target page content/docs/administration/concepts/billing-managers.md exists and states: "The Billing Manager role gives customers the ability to have someone in their Pulumi Organization manage billing operations without granting…; source: repo:content/docs/administration/concepts/billing-managers.md)
• L192 in content/docs/administration/concepts/organizations.md "The Pulumi docs and the Pulumi console refer to an organization's backing SAML/identity configuration as the organization's 'identity provider', configured…" → ➖ not-a-claim (evidence: The claim is a restatement of the file's own line 192: "The docs and the console call it the organization's identity provider, and you configure it under Membership Requirements..." This is the PR author's own editorial description of…; source: repo:content/docs/administration/concepts/organizations.md (line 192, same file as claim))
• L203 in content/docs/administration/concepts/organizations.md "The SAML-conversion prerequisite is written out as hand-authored prose here, while the same changeset introduces the saml-conversion-prereq shortcode and uses it on the seven SAML guide pages." → ✅ verified (evidence: layouts/shortcodes/saml-conversion-prereq.html is added by this PR and included on saml/_index.md, auth0.md, entra.md, gsuite.md, jumpcloud.md, okta.md, and onelogin.md; organizations.md L203 restates the same rule in its own words instead; source: gh pr diff 21110 -R pulumi/docs)
• L203 in content/docs/administration/concepts/organizations.md "Switching a Pulumi organization to SAML requires that the admin making the change does not belong to any other, unrelated Pulumi organizations." → ✅ verified (evidence: The shortcode saml-conversion-prereq.html (included on the SAML guide page) states: "The admin who makes this change can't belong to other, unrelated Pulumi organizations. Pulumi rejects the switch to SAML otherwise..." This…; source: layouts/shortcodes/saml-conversion-prereq.html; content/docs/administration/guides/saml/_index.md)
• L215-217 in content/docs/administration/concepts/organizations.md "Switching a Pulumi organization away from SAML discards the organization's SAML configuration, including its SAML identities, its SAML member roster, and its…" → 🤝 matches (evidence: The SCIM guide page states: "Your organization's SCIM access token is tied to its SAML configuration. If an admin switches the organization to a different identity provider, that configuration is discarded along with the SCIM token, the…; source: content/docs/administration/guides/scim/_index.md L116-120)
• L249 in content/docs/administration/concepts/organizations.md "Bitbucket calls its organizational grouping construct a 'workspace', per Atlassian's Bitbucket Cloud documentation." → ✅ verified (evidence: Atlassian's Bitbucket Cloud documentation confirms: "A workspace is where you will create repositories, collaborate on your code, and organize different streams of work in your Bitbucket Cloud account," confirming 'workspace' is…; source: https://support.atlassian.com/bitbucket-cloud/docs/what-is-a-workspace/)
• L249 in content/docs/administration/concepts/organizations.md "Bitbucket Cloud workspaces are documented at the Atlassian support URL https://support.atlassian.com/bitbucket-cloud/docs/what-is-a-workspace/." → ✅ verified (evidence: The pre-fetched page at https://support.atlassian.com/bitbucket-cloud/docs/what-is-a-workspace/ returns HTTP 200 and its title/content confirm it is Atlassian's "What is a workspace?" documentation: "A Bitbucket Cloud workspace contains…; source: https://support.atlassian.com/bitbucket-cloud/docs/what-is-a-workspace/)
• L253 in content/docs/administration/concepts/organizations.md "An admin of the Atlassian Bitbucket workspace must first grant the Pulumi OAuth app read access, per the scopes documented at…" → ✅ verified (evidence: The cited Atlassian Confluence page returns HTTP 200 and is the official "Use OAuth on Bitbucket Cloud" documentation covering OAuth consumer setup and scopes for Bitbucket Cloud, which is the page the claim references for OAuth scope…; source: https://confluence.atlassian.com/bitbucket/oauth-on-bitbucket-cloud-238027431.html#OAuthonBitbucketCloud-Scopes)
• L256-259 in content/docs/administration/concepts/organizations.md "Granting the Pulumi OAuth app read access to a Bitbucket workspace is not sufficient by itself to connect a Bitbucket-backed organization; the person making…" → ✅ verified (framing: Source states the admin must perform the grant; claim additionally specifies that granting alone (by a non-admin) is insufficient, which is the logical…; evidence: (escalated from pass1) Pulumi's official docs state: "To add a Bitbucket-backed organization to Pulumi, an admin of the Atlassian Bitbucket workspace must first grant the Pulumi Oauth app read access to their Bitbucket account and…; source: https://www.pulumi.com/docs/administration/organizations-teams/organizations/)
• L259 in content/docs/administration/concepts/organizations.md "A personal Bitbucket account with no workspace cannot be used to back a Pulumi organization." → ✅ verified (evidence: The doc explicitly states: "A personal Bitbucket account with no workspace won't work. Pulumi backs the organization with a workspace, so the account has to have one." This directly matches the claim as written.; source: content/docs/administration/concepts/organizations.md:L259)
• L262 in content/docs/administration/concepts/organizations.md "Adding a Bitbucket workspace member to a Pulumi organization is a separate step from that member's Bitbucket workspace membership." → ✅ verified (evidence: The same doc states: "Once the Pulumi organization has been created, the admin can see a list of Bitbucket workspace members that they can add or invite to the Pulumi organization. Adding them is a separate step from their workspace…; source: content/docs/administration/concepts/organizations.md)
• L264 in content/docs/administration/concepts/organizations.md "Pulumi labels the Bitbucket identity connection after Atlassian rather than Bitbucket: the control in account settings is labeled 'Connect Atlassian', and a…" → ✅ verified (framing: Blog confirms account settings uses "Atlassian" terminology for connecting identity (which includes Bitbucket); exact UI label text ('Connect Atlassian') not…; evidence: (escalated from pass1) Pulumi's own blog confirms the labeling convention: "If you want to connect your Atlassian identity to an existing Pulumi account, then navigate to https://app.pulumi.com and once logged in, head to Account…; source: https://www.pulumi.com/blog/pulumi-now-supports-atlassian-identity/)
• L36 in content/docs/administration/guides/saml/_index.md "The Pulumi documentation includes a page titled 'Organization-managed users' at /docs/administration/concepts/org-managed-users/ that covers this topic." → ✅ verified (evidence: The file content/docs/administration/concepts/org-managed-users.md exists, has title "Organization-Managed Users", and its content ("An organization-managed user is a Pulumi Cloud account that belongs to an organization rather than to an…; source: repo:content/docs/administration/concepts/org-managed-users.md)
• L36 in content/docs/administration/guides/saml/_index.md "A Pulumi account that already existed before connecting a SAML identity retains the abilities to join unrelated organizations, connect other identity…" → 🤷 unverifiable (evidence: (escalated from pass1) The cited page /docs/administration/concepts/org-managed-users/ did not surface in web search results, and no other Pulumi doc page directly confirms the specific claim that pre-existing accounts retain the ability…; source: WebSearch ran query "pulumi org-managed-users SAML identity account retains abilities join organizations"; top results didn't address the specific claim)
• L58 in content/docs/administration/guides/saml/_index.md "The Pulumi documentation includes a section on 'Disconnecting identity providers' at /docs/administration/concepts/organizations/#disconnecting-identity-provid…" → ✅ verified (evidence: gh search code confirmed the file content/docs/administration/concepts/organizations.md contains a heading "### Disconnecting identity providers", matching the anchor and URL cited…; source: gh search code --owner pulumi "Disconnecting identity providers" -> pulumi/docs:content/docs/administration/concepts/organizations.md)
• L51-53 in content/docs/administration/guides/saml/auth0.md "Configuring SAML for a Pulumi organization has a prerequisite condition described by the 'saml-conversion-prereq' notice, which must be satisfied before…" → ✅ verified (evidence: The shortcode saml-conversion-prereq is rendered as an info notice immediately before the "To configure Pulumi with the SAML metadata" steps, and its content states: "The admin who makes this change can't belong to other, unrelated…; source: repo:layouts/shortcodes/saml-conversion-prereq.html and repo:content/docs/administration/guides/saml/auth0.md L49-55)
• L92-94 in content/docs/administration/guides/saml/entra.md "Configuring a Pulumi organization to accept SAML SSO requests from Entra ID requires a SAML conversion prerequisite to be met beforehand (per the referenced…" → ✅ verified (evidence: The doc embeds the saml-conversion-prereq shortcode right before the org-configuration steps, and the shortcode text states: "The admin who makes this change can't belong to other, unrelated Pulumi organizations. Pulumi rejects the…; source: repo:layouts/shortcodes/saml-conversion-prereq.html and repo:content/docs/administration/guides/saml/entra.md (L92-94))
• L96-97 in content/docs/administration/guides/saml/entra.md "To configure a Pulumi organization to accept SAML SSO requests from Entra ID, you need to download the SAML application's configuration data and then pass…" → ➖ not-a-claim (evidence: The claim is a paraphrase of the doc's own sentence at lines 96-97: "To configure your Pulumi organization to accept SAML SSO requests from Entra ID, you will need to download the SAML application's configuration data and then pass that…; source: repo:content/docs/administration/guides/saml/entra.md)
• L85-87 in content/docs/administration/guides/saml/gsuite.md "There is a shortcode-based prerequisite note ('saml-conversion-prereq') that must be satisfied or reviewed before configuring SAML SSO for a Pulumi…" → ✅ verified (evidence: The file gsuite.md contains {{% notes type="info" %}}{{< saml-conversion-prereq >}}{{% /notes %}} immediately before the numbered steps that select the Other tab to configure SAML SSO, and the shortcode itself reads: "The admin who…; source: content/docs/administration/guides/saml/gsuite.md; layouts/shortcodes/saml-conversion-prereq.html)
• L89-91 in content/docs/administration/guides/saml/gsuite.md "To configure SAML SSO for a Pulumi organization, users sign in to Pulumi Cloud, navigate to their organization, select Settings > Access Management, then…" → ✅ verified (evidence: The file itself states the steps: "Sign in to Pulumi Cloud and navigate to your organization. Select Settings > Access Management. Select the Other tab." This matches the identical navigation pattern independently documented in…; source: repo:content/docs/administration/guides/saml/gsuite.md (L89-91); repo:content/docs/administration/concepts/access-tokens.md)
• L82-84 in content/docs/administration/guides/saml/jumpcloud.md "There is a prerequisite step required before converting an organization to SAML SSO, referenced via the 'saml-conversion-prereq' shortcode, that applies when…" → ✅ verified (evidence: The shortcode saml-conversion-prereq is defined at layouts/shortcodes/saml-conversion-prereq.html and reads: "The admin who makes this change can't belong to other, unrelated Pulumi organizations. Pulumi rejects the switch to SAML…; source: repo:layouts/shortcodes/saml-conversion-prereq.html and repo:content/docs/administration/guides/saml/jumpcloud.md)
• L86-87 in content/docs/administration/guides/saml/jumpcloud.md "Signing in to Pulumi Cloud at https://app.pulumi.com and navigating to your organization is the first step in configuring your Pulumi organization for…" → ➖ not-a-claim (evidence: Line 86 of the same file reads "Sign in to Pulumi Cloud and navigate to your organization." as the first numbered step under "Configuring your Pulumi organization" — the claim is just a restatement of the doc's…; source: repo:content/docs/administration/guides/saml/jumpcloud.md)
• L87-88 in content/docs/administration/guides/saml/jumpcloud.md "In Pulumi Cloud's Access Management page, there is a 'Membership Requirements' section containing a 'Change requirements' option used to configure SAML SSO…" → 🤝 matches (evidence: Sibling SAML guides (auth0.md, gsuite.md, entra.md, okta.md, onelogin.md) and organizations.md all consistently describe navigating to Settings > Access Management, then the 'Membership Requirements' section with a 'Change requirements'…; source: gh search code --owner pulumi "Membership Requirements" "Change requirements" across pulumi/docs)
• L85-89 in content/docs/administration/guides/saml/okta.md "There is a prerequisite condition related to SAML conversion that applies before configuring your Pulumi organization for Okta-based SAML, as indicated by…" → ✅ verified (evidence: The okta.md file at lines 85-87 contains a notes block rendering the saml-conversion-prereq shortcode immediately before the "Configuring your Pulumi organization" instructions. The shortcode content reads: "The admin who makes this…; source: repo:layouts/shortcodes/saml-conversion-prereq.html and repo:content/docs/administration/guides/saml/okta.md)
• L89-90 in content/docs/administration/guides/saml/okta.md "To configure Pulumi Cloud with details on a new Okta-based SAML application, you need to obtain the IdP metadata document from Okta and then provide it to…" → 🤝 matches (evidence: The doc itself states: "To configure Pulumi Cloud with details on your new Okta-based SAML application, you need to obtain the IdP metadata document from Okta and then provide it to Pulumi," and the subsequent numbered steps (View SAML…; source: repo:content/docs/administration/guides/saml/okta.md)
• L89-91 in content/docs/administration/guides/saml/onelogin.md "A conversion prerequisite must be met before converting a Pulumi organization to SAML, as described in the 'saml-conversion-prereq' shortcode/notice." → ✅ verified (evidence: The onelogin.md file at lines 89-91 includes an info notice wrapping the saml-conversion-prereq shortcode, which reads: "The admin who makes this change can't belong to other, unrelated Pulumi organizations. Pulumi rejects the switch…; source: repo:layouts/shortcodes/saml-conversion-prereq.html and repo:content/docs/administration/guides/saml/onelogin.md)
• L93-94 in content/docs/administration/guides/saml/onelogin.md "To configure Pulumi Cloud with details on your new OneLogin-based SAML application, you need to obtain the IdP metadata document from OneLogin and then…" → ➖ not-a-claim (evidence: The sentence is the page's own procedural instruction, immediately followed by concrete steps (download SAML Metadata XML from OneLogin, paste into Pulumi Cloud's SAML SSO configuration) that carry out exactly what it describes — it's a…; source: repo:content/docs/administration/guides/saml/onelogin.md)
• L31 in content/docs/administration/guides/saml/saml-admin.md "Losing every login method other than single sign-on (as happens when a user stops being a SAML admin) is the same thing that happens to an…" (also L34) → ✅ verified (evidence: The org-managed-users page states an organization-managed account has "Single sign-on through the managing organization becomes the account's only authentication method," and explicitly notes the SAML admin role is "the exception to the…; source: repo:content/docs/administration/concepts/org-managed-users.md)
• L36 in content/docs/administration/guides/saml/saml-admin.md "Only one SAML admin per organization is supported at this time." → 🤷 unverifiable (evidence: The doc describes a single "SAML Admin" dropdown for selecting one admin, consistent with the claim, but the only independent signal found — the pulumi-pulumiservice API type ListSAMLOrganizationAdminsResponse with field `SAMLAdmins…; source: gh api repos/pulumi/pulumi-pulumiservice/contents/provider/pkg/apitype/list_s_a_m_l_organization_admins_response_.go; intuition: The underlying API type is plural (list of SAML admins), which is mildly in tension with a hard "only one" product…)
• L77-79 in content/docs/administration/guides/scim/_index.md "The page 'Organization-managed users' at /docs/administration/concepts/org-managed-users/ contains the full set of restrictions on SCIM-created accounts." → ✅ verified (evidence: The page content/docs/administration/concepts/org-managed-users.md exists at /docs/administration/concepts/org-managed-users/ and contains a "## Restrictions" section stating "An organization-managed user is subject to three restrictions…; source: repo:content/docs/administration/concepts/org-managed-users.md)
• L81 in content/docs/administration/guides/scim/_index.md "The organization-managed-user restriction does not apply retroactively: someone who already had a Pulumi account and joined the organization by invitation…" → ✅ verified (evidence: The sibling concept page "Organization-Managed Users" explicitly states: "The user created it, and later joined the organization by connecting its SAML identity or accepting an invitation | No [organization-managed]" and "An ordinary…; source: content/docs/administration/concepts/org-managed-users.md)
• L81 in content/docs/administration/guides/scim/_index.md "Someone who already had a Pulumi account and joined an organization by invitation keeps an ordinary (non-organization-managed) account even after SCIM starts…" → 🤷 unverifiable (evidence: (escalated from pass1) Web search surfaced general Pulumi SCIM/SSO docs and FAQ pages discussing conflict scenarios (e.g., existing account with same email/username) but none directly addressed the specific scenario of a user who joined…; source: WebSearch ran query "Pulumi SCIM FAQ organization-managed account existing user"; top results didn't address the claim; intuition: This describes precise internal account-state semantics of Pulumi's own SCIM system; better resolved via the actual…)
• L83-85 in content/docs/administration/guides/scim/_index.md "Pulumi has no endpoint for deleting a user through SCIM." → 🤷 unverifiable (evidence: (escalated from pass1) Official Pulumi SCIM docs (FAQ and IdP configuration guides for OneLogin/Okta/Entra) only discuss POST/PUT/PATCH operations and describe deprovisioning via role/team removal or deactivation, never mentioning a…; source: https://www.pulumi.com/docs/support/faq/scim/; intuition: Conflicting third-party source (Stitchflow) claims a DELETE endpoint exists, but it is not an authoritative Pulumi… (WebSearch dispatched but verification did not converge within the turn budget))
• L83-85 in content/docs/administration/guides/scim/_index.md "Setting active to false removes the user's access to the organization while preserving their account and its history." → ➖ not-a-claim (evidence: This is a paraphrase of the same document's own description of Pulumi's SCIM deprovisioning behavior ("Deprovisioning sets active to false, which removes the user's access to the organization while preserving their account and its…; source: repo:content/docs/administration/guides/scim/_index.md)
• L85 in content/docs/administration/guides/scim/_index.md "Deprovisioning a SCIM-managed user is reversible by reactivating the user in the identity provider (IdP)." → ✅ verified (evidence: (escalated from pass1) Pulumi's release notes state: "Organization Administrators can now remove a user from their identity provider which will deprovision the user in Pulumi, and then re-add them through the identity provider and they…; source: https://www.pulumi.com/blog/pulumi-release-notes-74/)
• L116-118 in content/docs/administration/guides/scim/_index.md "If an admin switches the organization to a different identity provider, that action discards the organization's SAML configuration, its SCIM token, its SAML…" → ✅ verified (framing: Anchor cited is #changing-identity-providers but the supporting warning text lives under the adjacent '### Disconnecting identity providers' heading in the…; evidence: content/docs/administration/concepts/organizations.md contains a warning under "### Disconnecting identity providers" that states: "Switching away from SAML discards the organization's SAML configuration and everything derived from it…; source: repo:content/docs/administration/concepts/organizations.md)
• L120 in content/docs/administration/guides/scim/_index.md "Switching an organization back to SAML after switching away does not restore the previously discarded SCIM token, SAML identities, or SAML member roster." → 🤷 unverifiable (evidence: (escalated from pass1) Public Pulumi docs pages on SCIM/SAML configuration (setup guides, FAQ, troubleshooting) do not document the specific behavior of switching an org from SCIM back to SAML and whether discarded…; source: WebSearch ran query "Pulumi SCIM SAML switching organization discarded token" and "Pulumi docs SCIM switching identity provider back to SAML roster"; top results (docs.pulumi.com SCIM/SAML guides, FAQ, troubleshooting) didn't address this specific behavior)
• L114 in content/docs/support/faq/pulumi-cloud.md "How a user obtains the identity that backs their company's organization depends on the kind of identity provider the organization uses." → ➖ not-a-claim (evidence: This is the PR's own explanatory text describing its own documented process (immediately followed by the concrete GitHub/GitLab/Atlassian and SAML/SSO cases in lines 116-122), not a third-party factual assertion that needs external…; source: repo:content/docs/support/faq/pulumi-cloud.md)
• L114-116 in content/docs/support/faq/pulumi-cloud.md "For organizations backed by GitHub, GitLab, or Atlassian (Bitbucket), a user connects the identity to their existing Pulumi account by navigating to their…" → 🤷 unverifiable (evidence: The cited URL (https://app.pulumi.com/signin) returns only a sign-in page shell ("Pulumi Cloud") with no content describing account linking or identity provider connection flows, so the specific claim about connecting…; source: https://app.pulumi.com/signin)
• L118 in content/docs/support/faq/pulumi-cloud.md "A user does not have to sign in to Pulumi Cloud using the same identity provider (GitHub, GitLab, or Bitbucket) that backs the organization; signing in with…" → ✅ verified (evidence: The sibling concept page independently confirms the same mechanism: "Connecting an identity doesn't add you to the organizations that identity backs... you must connect your account with the organization's backing identity provider" and…; source: content/docs/administration/concepts/organizations.md, content/docs/administration/concepts/accounts.md)
• L118 in content/docs/support/faq/pulumi-cloud.md "What matters for linking an account to an organization is that the identity is connected to the account and that it belongs to the GitHub organization…" → ✅ verified (evidence: The organizations.md sibling doc corroborates this model: "To become a member of a Pulumi organization... you also need to be a member of the third-party organization or group backing the Pulumi organization" and "Once you connect the…; source: content/docs/administration/concepts/organizations.md)
• L120 in content/docs/support/faq/pulumi-cloud.md "For organizations backed by SAML/SSO, linking an existing Pulumi account requires completing a single sign-on through the identity provider, because…" → ✅ verified (evidence: The cited anchor "Connect SAML SSO to an existing account" in content/docs/administration/guides/saml/_index.md states: "connect that organization's SAML SSO identity to your existing account... Sign in to Pulumi Cloud with your existing…; source: repo:content/docs/administration/guides/saml/_index.md#connect-saml-sso-to-an-existing-account)

---

• Refresh this review — comment @claude #update-review. Say what you fixed, or which finding you dispute and why; both work in the same mention.
• Ask for anything else — comment @claude with no hashtag (questions, one-off fixes). Leaves this review untouched.

Important

Please don't hide, resolve, or delete this comment! It breaks things!

📖 How pre-merge review works — the full lifecycle, short-circuits, and escape hatches.

[github-actions]

continued from previous comment

• L122 in content/docs/support/faq/pulumi-cloud.md "Pulumi's documentation includes a page or section titled 'If the identity options aren't there' at /docs/administration/concepts/accounts/#identity-options-mis…" → ✅ verified (evidence: content/docs/administration/concepts/accounts.md contains the heading '#### If the identity options aren't there {#identity-options-missing}', matching the linked section at /docs/administration/concepts/accounts/#identity-options-missing.; source: repo:content/docs/administration/concepts/accounts.md)

🚨 Outstanding in this PR

These must be resolved or refuted before merging.

• [L203] content/docs/administration/concepts/organizations.md — the SAML-conversion prerequisite is duplicated as hand-written prose here, even though this same PR introduces layouts/shortcodes/saml-conversion-prereq.html and uses it on all seven SAML guide pages. Two copies of the same normative rule will drift; AGENTS.md asks for shortcodes for shared content rather than copy-pasted Markdown. Swap the paragraph for the shortcode:

  Switching an organization to SAML has one further prerequisite. {{< saml-conversion-prereq >}}

  If you'd rather keep the sentence in the surrounding narrative voice than open a callout mid-section, that's a fair call — say so and this closes. What shouldn't ship is the rule existing in two independently editable places.

⚠️ Low-confidence

Review each and resolve as appropriate — these don't block the PR.

• [L35] content/docs/administration/concepts/org-managed-users.md — "An ordinary account that joins a SAML organization keeps everything an ordinary account has… it can still belong to other organizations, connect other identity providers, and create organizations." — this is the load-bearing half of the page's central distinction, and it's the sentence a reader will act on when deciding whether connecting SAML to an existing account is safe. It couldn't be confirmed against any public source. Can you confirm with the identity/console team that an ordinary account joining a SAML org really keeps all three capabilities, and that none of them is silently curtailed once a SAML identity is attached?

• [L41] content/docs/administration/concepts/org-managed-users.md — "The account can belong to the organization that manages it, and to organizations related to that one as part of a multi-organization arrangement." — no public source describes this carve-out, and multi-organization appears twice on this page (here and in the Additional identities bullet, "A user managed by a multi-organization is the one exception") without a definition or a link. A reader hitting a rejected invitation has no way to tell whether their situation is the exception. Two asks: confirm the behavior, and either link "multi-organization arrangement" to wherever it's defined or add a one-sentence gloss on first use.

• [L47] content/docs/administration/concepts/org-managed-users.md — "Migrating an ordinary account to an organization-managed one is permanent and destructive, and it takes effect immediately." — of everything on the page, this is the sentence with the worst failure mode if it's wrong: a reader who believes there's a confirmation step or a grace period, and there isn't one, loses their other organizations and every linked identity. Worth confirming with the console team that the control applies immediately with no second confirmation, and, if the UI does show a confirmation dialog, saying so here.

• [L61-62] content/docs/administration/concepts/org-managed-users.md — "Navigate to Account settings. Under your email address, select Migrate to Org-Managed Account." — the general "Account settings, under your email address" pattern matches other Pulumi Cloud docs, but the exact control label couldn't be confirmed from any public source. UI labels are the fastest thing in a doc to go stale and the most frustrating to a reader who can't find the button. Please confirm the label character-for-character against the console (including the hyphenation of "Org-Managed"), and consider a screenshot — the sibling customer-managed-keys.md uses that pattern for its console steps.

• [L36] content/docs/administration/guides/saml/_index.md — "An account that already existed and later connects a SAML identity keeps those abilities." — same unconfirmed behavior as the org-managed-users.md L35 bullet above, restated on the SAML guide. Confirming it once settles both; if the answer changes the wording, both sentences need the edit, since they're the two places a reader is most likely to land.

• [L81] content/docs/administration/guides/scim/_index.md — "This does not apply retroactively. Someone who already had a Pulumi account and joined your organization by invitation keeps an ordinary account, even after SCIM starts managing their membership." — this is the one sentence an admin rolling out SCIM to an existing organization will read most carefully, since it decides whether their existing members quietly become organization-managed. It's consistent with the new concept page's table, but nothing outside this changeset confirms it. Worth an engineering confirmation that SCIM adoption never reclassifies an existing invited account.

• [L83-85] content/docs/administration/guides/scim/_index.md — "Pulumi has no endpoint for deleting a user through SCIM." — this sentence is pre-existing (the PR only inserts a new section above it), but it's worth a look while you're in the file: Pulumi's own SCIM docs never mention a DELETE endpoint, which supports it, while at least one third-party integration directory asserts one exists. The check didn't converge either way. If a DELETE endpoint does exist and simply isn't recommended, "has no endpoint" would be the wrong reason to give for advice that's otherwise right.

• [L120] content/docs/administration/guides/scim/_index.md — "Switching back to SAML doesn't restore any of it. You have to issue a new SCIM token, point your identity provider at it, and re-provision your users." — the discard half of this is corroborated by the matching warning you added to organizations.md, but the non-restoration half — specifically that the SAML member roster doesn't come back — isn't confirmed anywhere public. That distinction matters: "re-provision your users" is a materially bigger operation than "reissue a token." Confirm the roster really is gone, not just the token.

📋 Triaged verifier findings

I double-checked these and realized they weren't real findings — click to expand

• [L114-116] content/docs/support/faq/pulumi-cloud.md — "For GitHub, GitLab, and Atlassian (Bitbucket), connect the identity to your existing account…" — Mis-sourced: the check followed https://app.pulumi.com/signin, which is a sign-in shell that renders its content client-side and can't confirm anything about account settings. The same flow is documented on the sibling pages content/docs/administration/concepts/organizations.md and content/docs/administration/concepts/accounts.md, both of which describe connecting the backing identity from your profile before an admin can add you.

• [L28] content/docs/administration/concepts/customer-managed-keys.md — "Only organization admins can manage CMKs." — Mis-sourced: the claim was extracted from a line this PR doesn't touch (the only change to this file is a menu weight bump from 8 to 9), and it's an internal Pulumi Cloud access-control rule with no public reference page to check it against. Nothing here for this PR to act on.

💡 Pre-existing issues in touched files (optional)

• [L36] content/docs/administration/guides/saml/saml-admin.md — Pre-existing: "Only one SAML admin per organization is supported at this time." sits on a line this PR doesn't touch (the PR adds the sentence above it), but it may be stale. The Pulumi service API exposes ListSAMLOrganizationAdminsResponse with a plural SAMLAdmins field, which is mildly in tension with a hard one-admin limit — the plural could be forward-looking, or the limit could have been lifted. Since the new page now leans on the SAML admin role as the documented exception to the single-authentication-method rule, it's worth a quick confirmation, though it's fair to leave for a follow-up rather than expand this PR.

✅ Resolved since last review

No items resolved since the last review.

📜 Review history

• 2026-08-25T00:55:54Z — Mechanics clean (build, links, anchors, menu-weight renumbering across all 9 concept pages); one duplicated SAML-conversion prerequisite to route through the new shortcode, and eight unconfirmed Pulumi Cloud behaviors on the migration and SCIM paths that need an author confirmation. (be285bb)

---

• Refresh this review — comment @claude #update-review. Say what you fixed, or which finding you dispute and why; both work in the same mention.
• Ask for anything else — comment @claude with no hashtag (questions, one-off fixes). Leaves this review untouched.

Important

Please don't hide, resolve, or delete this comment! It breaks things!

📖 How pre-merge review works — the full lifecycle, short-circuits, and escape hatches.

[pulumi-bot]

Your site preview for commit be285bb is ready! 🎉

http://www-testing-pulumi-docs-origin-pr-21110-be285bb2.s3-website.us-west-2.amazonaws.com

Changed pages:

• /docs/administration/concepts/
• /docs/administration/concepts/access-tokens/
• /docs/administration/concepts/accounts/
• /docs/administration/concepts/agent-accounts/
• /docs/administration/concepts/audit-logs/
• /docs/administration/concepts/billing-managers/
• /docs/administration/concepts/customer-managed-keys/
• /docs/administration/concepts/org-managed-users/
• /docs/administration/concepts/organizations/
• /docs/administration/concepts/rbac/
• /docs/administration/guides/saml/
• /docs/administration/guides/saml/auth0/
• /docs/administration/guides/saml/entra/
• /docs/administration/guides/saml/gsuite/
• /docs/administration/guides/saml/jumpcloud/
• /docs/administration/guides/saml/okta/
• /docs/administration/guides/saml/onelogin/
• /docs/administration/guides/saml/saml-admin/
• /docs/administration/guides/scim/
• /docs/support/faq/pulumi-cloud/

[pulumi-bot]

Lighthouse Performance Report

Commit: be285bb | Metric definitions

Page	Device	Score	FCP	LCP	TBT	CLS	SI
Homepage	Mobile	🔴 46	3.7s	8.5s	794ms	0.074	4.3s
Homepage	Desktop	🟢 94	0.7s	1.0s	174ms	0.012	0.8s
Install Pulumi	Mobile	🟡 61	5.5s	7.5s	82ms	0.054	5.5s
Install Pulumi	Desktop	🟡 84	1.1s	2.6s	0ms	0.006	1.1s
AWS Get Started	Mobile	🔴 45	5.4s	13.5s	91ms	0.325	5.4s
AWS Get Started	Desktop	🟡 84	1.0s	2.4s	0ms	0.061	1.0s