---
id: FAS-PFM-SEC-03
title: People and Access Administration acceptance
feature: FEAT-PFM-SEC-03
product_area: platform
module: security
revision: 2
status: proposed
product_intent: proposed
source_sha:
  services-platform: ad3f6a6582843008ed0f5a17b131878d15829af1
  react-console: baf6dae382d6f41dce976c7f848667ccc37e076f
capabilities:
  - CAP-PFM-SEC-008
  - CAP-PFM-SEC-009
  - CAP-PFM-SEC-010
  - CAP-PFM-SEC-011
scenarios:
  - id: FAS-PFM-SEC-03-01
    title: Keep colleague administration tied to one identity
    kind: behaviour
    exercises:
      - CAP-PFM-SEC-008
      - CAP-PFM-SEC-009
      - CAP-PFM-SEC-010
      - CAP-PFM-SEC-011
    relies_on:
      - ATS-PFM-SEC-008-11
      - ATS-PFM-SEC-009-11
      - ATS-PFM-SEC-010-13
      - ATS-PFM-SEC-011-01
    preconditions: Prepare two qualifying administrators so maintenance cannot strand the customer.
    steps:
      - do: >-
          Invite a colleague, read pending access, maintain the accepted profile, assign a role and
          inspect the recorded history.
        expect: 'The account, role assignment and administrative events identify the same colleague.'
        provenance: proposed
        source:
          - >-
            react-console:e2e/security/invitations.spec.ts#invites a new identity from the Users
            screen
          - >-
            react-console:e2e/security/users.spec.ts#edits a person's details and keeps them through
            a reload
          - >-
            react-console:e2e/security/users.spec.ts#gives a role, says who granted it, and takes it
            away again
          - >-
            services-platform:modules/security/tests/integration/services/persistence/audit-events.integration.spec.js#records
            the actor in their wall, the session, the keys, before and after, and the request
    expected: 'The account, role assignment and administrative events identify the same colleague.'
    negative: false
    data_needs: >-
      Disposable customer, workspace and membership fixtures owned by the run; fixed clocks, failure
      controls or provider prerequisites as required by the case.
    bound_to: []
    provenance: proposed
    source:
      - 'react-console:e2e/security/invitations.spec.ts#invites a new identity from the Users screen'
      - >-
        react-console:e2e/security/users.spec.ts#edits a person's details and keeps them through a
        reload
      - >-
        react-console:e2e/security/users.spec.ts#gives a role, says who granted it, and takes it
        away again
      - >-
        services-platform:modules/security/tests/integration/services/persistence/audit-events.integration.spec.js#records
        the actor in their wall, the session, the keys, before and after, and the request
    action_evidence:
      provenance: proposed
      source:
        - >-
          react-console:e2e/security/invitations.spec.ts#invites a new identity from the Users
          screen
        - >-
          react-console:e2e/security/users.spec.ts#edits a person's details and keeps them through a
          reload
        - >-
          react-console:e2e/security/users.spec.ts#gives a role, says who granted it, and takes it
          away again
        - >-
          services-platform:modules/security/tests/integration/services/persistence/audit-events.integration.spec.js#records
          the actor in their wall, the session, the keys, before and after, and the request
    assertion_evidence:
      provenance: proposed
      source:
        - >-
          react-console:e2e/security/invitations.spec.ts#invites a new identity from the Users
          screen
        - >-
          react-console:e2e/security/users.spec.ts#edits a person's details and keeps them through a
          reload
        - >-
          react-console:e2e/security/users.spec.ts#gives a role, says who granted it, and takes it
          away again
        - >-
          services-platform:modules/security/tests/integration/services/persistence/audit-events.integration.spec.js#records
          the actor in their wall, the session, the keys, before and after, and the request
    execution_gap: FND-PFM-SEC-078
  - id: FAS-PFM-SEC-03-02
    title: Keep the person’s assignment and role-holder view consistent
    kind: interaction
    exercises:
      - CAP-PFM-SEC-009
      - CAP-PFM-SEC-010
    relies_on:
      - ATS-PFM-SEC-009-01
      - ATS-PFM-SEC-010-13
    preconditions: Prepare an active colleague and a customer-owned custom role.
    steps:
      - do: >-
          Assign the role on the person’s record, read the role’s Members view, withdraw the
          assignment and read that view again.
        expect: >-
          The person appears as a holder while assigned and disappears from the live-holder view
          after withdrawal.
        provenance: proposed
        source:
          - >-
            services-platform:modules/security/tests/e2e/console-users.e2e.spec.js#answers a page of
            the customer’s console users, by surname
          - >-
            react-console:e2e/security/users.spec.ts#gives a role, says who granted it, and takes it
            away again
    expected: >-
      The person appears as a holder while assigned and disappears from the live-holder view after
      withdrawal.
    negative: false
    data_needs: >-
      Disposable customer, workspace and membership fixtures owned by the run; fixed clocks, failure
      controls or provider prerequisites as required by the case.
    bound_to: []
    provenance: proposed
    source:
      - >-
        services-platform:modules/security/tests/e2e/console-users.e2e.spec.js#answers a page of the
        customer’s console users, by surname
      - >-
        react-console:e2e/security/users.spec.ts#gives a role, says who granted it, and takes it
        away again
    action_evidence:
      provenance: proposed
      source:
        - >-
          services-platform:modules/security/tests/e2e/console-users.e2e.spec.js#answers a page of
          the customer’s console users, by surname
        - >-
          react-console:e2e/security/users.spec.ts#gives a role, says who granted it, and takes it
          away again
    assertion_evidence:
      provenance: proposed
      source:
        - >-
          services-platform:modules/security/tests/e2e/console-users.e2e.spec.js#answers a page of
          the customer’s console users, by surname
        - >-
          react-console:e2e/security/users.spec.ts#gives a role, says who granted it, and takes it
          away again
    execution_gap: FND-PFM-SEC-078
  - id: FAS-PFM-SEC-03-03
    title: Reinvite without reusing a withdrawn offer
    kind: lifecycle
    exercises:
      - CAP-PFM-SEC-008
      - CAP-PFM-SEC-009
      - CAP-PFM-SEC-010
    relies_on:
      - ATS-PFM-SEC-008-03
      - ATS-PFM-SEC-008-08
      - ATS-PFM-SEC-009-05
      - ATS-PFM-SEC-010-05
    preconditions: Prepare an outstanding invitation with pending assignments.
    steps:
      - do: 'Withdraw the invitation, attempt its link and invite the same address again.'
        expect: >-
          The withdrawn link grants no access; a new offer and pending assignments use the retained
          membership.
        provenance: proposed
        source:
          - >-
            services-platform:modules/security/tests/e2e/invitations.e2e.spec.js#refuses an
            invitation to somebody who has already accepted, pointing at their roles instead
          - >-
            services-platform:modules/security/tests/e2e/invitations.e2e.spec.js#revoking a
            membership stops the link already in the inbox, and the account cannot come back by
            accepting it
          - >-
            services-platform:modules/security/tests/e2e/invitations.e2e.spec.js#revokes a
            membership with every assignment it held, and nothing undoes it
          - >-
            services-platform:modules/security/tests/integration/services/membership/manage-assignments.integration.spec.js#grants
            a role at customer scope, active at once for an active person, and audits it as widening
    expected: >-
      The withdrawn link grants no access; a new offer and pending assignments use the retained
      membership.
    negative: true
    data_needs: >-
      Disposable customer, workspace and membership fixtures owned by the run; fixed clocks, failure
      controls or provider prerequisites as required by the case.
    bound_to: []
    provenance: proposed
    source:
      - >-
        services-platform:modules/security/tests/e2e/invitations.e2e.spec.js#refuses an invitation
        to somebody who has already accepted, pointing at their roles instead
      - >-
        services-platform:modules/security/tests/e2e/invitations.e2e.spec.js#revoking a membership
        stops the link already in the inbox, and the account cannot come back by accepting it
      - >-
        services-platform:modules/security/tests/e2e/invitations.e2e.spec.js#revokes a membership
        with every assignment it held, and nothing undoes it
      - >-
        services-platform:modules/security/tests/integration/services/membership/manage-assignments.integration.spec.js#grants
        a role at customer scope, active at once for an active person, and audits it as widening
    action_evidence:
      provenance: proposed
      source:
        - >-
          services-platform:modules/security/tests/e2e/invitations.e2e.spec.js#refuses an invitation
          to somebody who has already accepted, pointing at their roles instead
        - >-
          services-platform:modules/security/tests/e2e/invitations.e2e.spec.js#revoking a membership
          stops the link already in the inbox, and the account cannot come back by accepting it
        - >-
          services-platform:modules/security/tests/e2e/invitations.e2e.spec.js#revokes a membership
          with every assignment it held, and nothing undoes it
        - >-
          services-platform:modules/security/tests/integration/services/membership/manage-assignments.integration.spec.js#grants
          a role at customer scope, active at once for an active person, and audits it as widening
    assertion_evidence:
      provenance: proposed
      source:
        - >-
          services-platform:modules/security/tests/e2e/invitations.e2e.spec.js#refuses an invitation
          to somebody who has already accepted, pointing at their roles instead
        - >-
          services-platform:modules/security/tests/e2e/invitations.e2e.spec.js#revoking a membership
          stops the link already in the inbox, and the account cannot come back by accepting it
        - >-
          services-platform:modules/security/tests/e2e/invitations.e2e.spec.js#revokes a membership
          with every assignment it held, and nothing undoes it
        - >-
          services-platform:modules/security/tests/integration/services/membership/manage-assignments.integration.spec.js#grants
          a role at customer scope, active at once for an active person, and audits it as widening
    execution_gap: FND-PFM-SEC-078
  - id: FAS-PFM-SEC-03-04
    title: Read access does not permit administration or explanation
    kind: permission
    exercises:
      - CAP-PFM-SEC-008
      - CAP-PFM-SEC-009
      - CAP-PFM-SEC-010
      - CAP-PFM-SEC-011
    relies_on:
      - ATS-PFM-SEC-008-05
      - ATS-PFM-SEC-009-02
      - ATS-PFM-SEC-010-01
      - ATS-PFM-SEC-011-05
    preconditions: Prepare a reader and an access manager who can view the same colleague.
    steps:
      - do: >-
          Attempt invitation, profile editing, role assignment and history explanation under
          identities with independently selected keys.
        expect: Each missing management or explanation key causes refusal without the attempted write.
        provenance: proposed
        source:
          - >-
            services-platform:modules/security/tests/e2e/invitations.e2e.spec.js#lets a caller grant
            a role whose every key they are allowed where they are granting it
          - >-
            services-platform:modules/security/tests/e2e/console-users.e2e.spec.js#changes the names
            and answers the person again, at the next version
          - >-
            services-platform:modules/security/tests/e2e/console-users.e2e.spec.js#refuses the
            reader’s attempt to grant as 403, and grants nothing
          - >-
            services-platform:modules/security/tests/e2e/console-users.e2e.spec.js#refuses the
            reader, who may not read the history either
    expected: Each missing management or explanation key causes refusal without the attempted write.
    negative: true
    data_needs: >-
      Disposable customer, workspace and membership fixtures owned by the run; fixed clocks, failure
      controls or provider prerequisites as required by the case.
    bound_to: []
    provenance: proposed
    source:
      - >-
        services-platform:modules/security/tests/e2e/invitations.e2e.spec.js#lets a caller grant a
        role whose every key they are allowed where they are granting it
      - >-
        services-platform:modules/security/tests/e2e/console-users.e2e.spec.js#changes the names and
        answers the person again, at the next version
      - >-
        services-platform:modules/security/tests/e2e/console-users.e2e.spec.js#refuses the reader’s
        attempt to grant as 403, and grants nothing
      - >-
        services-platform:modules/security/tests/e2e/console-users.e2e.spec.js#refuses the reader,
        who may not read the history either
    action_evidence:
      provenance: proposed
      source:
        - >-
          services-platform:modules/security/tests/e2e/invitations.e2e.spec.js#lets a caller grant a
          role whose every key they are allowed where they are granting it
        - >-
          services-platform:modules/security/tests/e2e/console-users.e2e.spec.js#changes the names
          and answers the person again, at the next version
        - >-
          services-platform:modules/security/tests/e2e/console-users.e2e.spec.js#refuses the
          reader’s attempt to grant as 403, and grants nothing
        - >-
          services-platform:modules/security/tests/e2e/console-users.e2e.spec.js#refuses the reader,
          who may not read the history either
    assertion_evidence:
      provenance: proposed
      source:
        - >-
          services-platform:modules/security/tests/e2e/invitations.e2e.spec.js#lets a caller grant a
          role whose every key they are allowed where they are granting it
        - >-
          services-platform:modules/security/tests/e2e/console-users.e2e.spec.js#changes the names
          and answers the person again, at the next version
        - >-
          services-platform:modules/security/tests/e2e/console-users.e2e.spec.js#refuses the
          reader’s attempt to grant as 403, and grants nothing
        - >-
          services-platform:modules/security/tests/e2e/console-users.e2e.spec.js#refuses the reader,
          who may not read the history either
    execution_gap: FND-PFM-SEC-078
  - id: FAS-PFM-SEC-03-05
    title: Lockout refusal survives transaction rollback
    kind: regression
    exercises:
      - CAP-PFM-SEC-009
      - CAP-PFM-SEC-010
      - CAP-PFM-SEC-011
    relies_on:
      - ATS-PFM-SEC-009-06
      - ATS-PFM-SEC-010-07
      - ATS-PFM-SEC-011-02
    preconditions: Leave one qualifying administrator for the customer.
    steps:
      - do: >-
          Try withdrawing that person’s final administrative role and suspending the membership;
          read the records and refusal events afterward.
        expect: >-
          The administrator remains usable and history attributes both refused actions despite
          rollback.
        provenance: proposed
        source:
          - >-
            services-platform:modules/security/tests/unit/services/invitations/suspend-revoke.spec.js#refuses
            a suspension that would leave the customer with no security administrator, and suspends
            nobody
          - >-
            services-platform:modules/security/tests/integration/services/membership/manage-assignments.integration.spec.js#revokes
            the grant, keeps the row, and audits what was withdrawn
          - >-
            services-platform:modules/security/tests/integration/services/invitations/revoke-lockout.integration.spec.js#records
            the refused attempt with the guard’s reason, outside the transaction that was rolled
            back
    expected: The administrator remains usable and history attributes both refused actions despite rollback.
    negative: true
    data_needs: >-
      Disposable customer, workspace and membership fixtures owned by the run; fixed clocks, failure
      controls or provider prerequisites as required by the case.
    bound_to: []
    provenance: proposed
    source:
      - >-
        services-platform:modules/security/tests/unit/services/invitations/suspend-revoke.spec.js#refuses
        a suspension that would leave the customer with no security administrator, and suspends
        nobody
      - >-
        services-platform:modules/security/tests/integration/services/membership/manage-assignments.integration.spec.js#revokes
        the grant, keeps the row, and audits what was withdrawn
      - >-
        services-platform:modules/security/tests/integration/services/invitations/revoke-lockout.integration.spec.js#records
        the refused attempt with the guard’s reason, outside the transaction that was rolled back
    action_evidence:
      provenance: proposed
      source:
        - >-
          services-platform:modules/security/tests/unit/services/invitations/suspend-revoke.spec.js#refuses
          a suspension that would leave the customer with no security administrator, and suspends
          nobody
        - >-
          services-platform:modules/security/tests/integration/services/membership/manage-assignments.integration.spec.js#revokes
          the grant, keeps the row, and audits what was withdrawn
        - >-
          services-platform:modules/security/tests/integration/services/invitations/revoke-lockout.integration.spec.js#records
          the refused attempt with the guard’s reason, outside the transaction that was rolled back
    assertion_evidence:
      provenance: proposed
      source:
        - >-
          services-platform:modules/security/tests/unit/services/invitations/suspend-revoke.spec.js#refuses
          a suspension that would leave the customer with no security administrator, and suspends
          nobody
        - >-
          services-platform:modules/security/tests/integration/services/membership/manage-assignments.integration.spec.js#revokes
          the grant, keeps the row, and audits what was withdrawn
        - >-
          services-platform:modules/security/tests/integration/services/invitations/revoke-lockout.integration.spec.js#records
          the refused attempt with the guard’s reason, outside the transaction that was rolled back
    execution_gap: FND-PFM-SEC-078
evidence:
  - >-
    specs/platform/security/planning/capabilities/CAP-PFM-SEC-008-invite-people-and-follow-their-invitations.md
  - >-
    specs/platform/security/planning/capabilities/CAP-PFM-SEC-009-maintain-people-s-console-accounts.md
  - >-
    specs/platform/security/planning/capabilities/CAP-PFM-SEC-010-give-and-take-away-roles-at-the-right-scope.md
  - >-
    specs/platform/security/planning/capabilities/CAP-PFM-SEC-011-review-who-changed-access-and-what-was-refused.md
  - >-
    Capability test scenario references identify the outcomes this suite relies on. The complete
    feature chains remain proposed until a suite executes every step.
examiner: codex
examined_at: '2026-10-23'
final_text: OpenAI
---
# People and Access Administration acceptance: Feature Acceptance Suite

## What the Feature Must Do as a Whole

The suite follows a colleague through invitation, account maintenance and changes to assigned roles. It checks that the person’s record, role-holder views and retained history describe the same administrative work.

## Interactions Between Capabilities

Invitations create pending access, membership changes affect its usability, and assignment changes affect both the person and the role’s holder view. Refused lockout changes must preserve a working administrator and retain their refusal evidence. The referenced capability scenarios supply detailed observations. These ordered feature cases remain proposed until a registered suite executes the whole chain and its result is retained.

## Regression Record

| Revision | Change | Scenario | Why |
|---|---|---|---|
| 1 | initial | all | Establish the feature’s cumulative acceptance baseline. |
| 2 | testing examination continuation | all | Verify references, write final feature text and keep execution gaps explicit. |