# Run and support the platform

Source: https://docs.settlemint.com/docs/changelog/dalp-3-1/platform-operations
Archive and restore organizations with an audit trail, reset a user's onboarding, invite people with their on-chain roles pre-assigned, and tighten KYC search and uniqueness.



**A platform that hosts many organizations for years accumulates operational debt: dormant organizations, stuck onboardings, memberships that arrive without their roles. DALP 3.1 gives you first-class, audited tools for each, so routine operations stop requiring database access.**

<Spotlight
  eyebrow="Operations Console"
  title="Admin tools, not database surgery"
  aside="
  <FactList
    items={[
      { label: &#x22;Archive&#x22;, value: &#x22;Reversible, with reason&#x22; },
      { label: &#x22;Onboarding reset&#x22;, value: &#x22;Wallets archived, not lost&#x22; },
      { label: &#x22;Invites&#x22;, value: &#x22;Roles granted on acceptance&#x22; },
      { label: &#x22;KYC&#x22;, value: &#x22;National ID unique per org&#x22; },
    ]}
  />
"
>
  Every operation on this page is an admin-only API call with an audit record:
  who acted, on what, and why. You run none of them from a shell, a cluster
  credential, or a manual database change.
</Spotlight>

The theme is closure: yesterday's support escalations are now governed operations you run yourself.

## Archive an organization, keep its history [#archive-an-organization-keep-its-history]

A platform operator winding down a client engagement needs the organization gone from daily use but intact for the record. Deletion destroys the audit trail; leaving it active invites accidental use. 3.1 adds the middle path:

```text
POST /api/v2/admin/organizations/{id}/archive
POST /api/v2/admin/organizations/{id}/restore
```

Archive is a soft state that records when, by whom, and for what reason. The platform refuses an archived organization at both activation paths: a user cannot switch to it explicitly, and a new session cannot select it implicitly. Membership cannot grow into it either, so an archived organization stays exactly as large as it was. Both endpoints are admin-only and land in the audit log, and restore brings the organization back whole.

## Reset a stuck onboarding [#reset-a-stuck-onboarding]

When a user's onboarding goes wrong, the historical answer was manual cleanup. Now an admin endpoint resets the user's onboarding in one call. The platform archives the user's wallets instead of deleting them, records your optional reason, and returns a summary of what it removed. The user starts onboarding fresh, and the platform keeps the record of what existed before.

<Callout title="Archived, not deleted">
  Both the onboarding reset and the organization archive keep history. Wallets
  move to an archived state instead of disappearing, and an archived
  organization stays whole until an admin restores it.
</Callout>

## Invite people with their roles ready [#invite-people-with-their-roles-ready]

Onboarding a new operator used to be two workflows: invite the person, then grant their on-chain roles once they arrive. A PIN-gated invitation route now pre-assigns system-level on-chain roles that the platform grants when the invitee accepts. The role fields are server-controlled, so the standard invitation path cannot set them, and the role picker offers only roles the inviter has the authority to grant. Resending an invitation preserves its roles.

<Steps>
  <Step title="Invite with roles">
    An administrator sends a PIN-gated invitation carrying the system-level
    on-chain roles the new member needs.
  </Step>

  <Step title="Accept">
    The invitee accepts and completes onboarding as usual.
  </Step>

  <Step title="Roles granted">
    The platform grants the pre-assigned roles on acceptance. No second
    workflow, no window where the member exists without the roles their job
    requires.
  </Step>
</Steps>

## KYC data you can search and trust [#kyc-data-you-can-search-and-trust]

A compliance reviewer working a large user base needs two things from identity data: find a person fast, and trust that an identifier is unique. The Users table free-text search now matches national ID, and Residency and Country facet filters join the table, part of a facet sweep across eight other tables. On the trust side, the platform now prevents a duplicate approved national ID within one organization. Pre-existing duplicates were not silently blessed: a backfill demoted them to under review, so a human decides which record stands.

## Compatibility [#compatibility]

Every capability on this page is additive: new admin routes, new invitation fields, and new database objects the upgrade creates on its own. No existing workflow changes shape. The national-ID uniqueness rule is the one behavior change: within one organization, the platform rejects a second KYC profile with the same approved national ID, and previously duplicated approvals moved to under review for a human decision.

[Invitation onboarding API →](/docs/developers/platform-setup/invitation-onboarding-api) · [Create and manage users →](/docs/developers/user-management/create-users) · [Organization membership reference →](/docs/api-reference/reference/organization-membership)