@salesforce/afv-skills 1.44.0 → 1.45.0

package/skills/service-itsm-slack-itservice-configure/references/manage-user-access.md

@@ -0,0 +1,117 @@
+# Manage User Access (Step 4) — assign Employee Slack Notifications
+
+The Go page's **"Manage User Access"** step (Salesforce Go → *Slack for Employee Service* → *Set Up the
+Basics* → **Manage**) centers on the permission set **`EmployeeSlackNotifications`** (label *"Employee
+Slack Notifications"*) — *"gives employee users the ability to receive notifications on ticket updates
+in Slack."* This skill assigns **all three core permsets** to each confirmed user —
+`EmployeeSlackNotifications` **plus** `ItsmPortalUelUserPermset` (record visibility) **plus** an
+API-Enabled permset (both detailed below) — never a notifications-only subset. Assign only to the
+specific employee user(s) who will use Slack — **never all active users**.
+
+> **Assign the right permset.** This employee-side step is **`EmployeeSlackNotifications`** (PSL
+> `EmployeeSlackNotificationsPsl`), **not** `SlackServiceUser` (PSL `SlackServiceUserPsl`) — that's a
+> separate fulfiller/service-side permset on a different path and does **not** satisfy this step. Query
+> by exact `Name = 'EmployeeSlackNotifications'`.
+
+> **The user's email must match their Slack user's email.** Assigning the permset only grants the
+> *ability* to receive Slack notifications — it does **not** create the Salesforce↔Slack user link. That
+> link is made by the connection's **account-mapping field** (default `Email`, chosen when the connection
+> was requested/approved): the Salesforce `User.Email` must equal the email of that person's Slack
+> account, otherwise they map to no Slack user and notifications never arrive. Warn the user and verify
+> the match — a `null` `currentUserMapping.salesforceUserId` from `GET /connect/slackbridge/connections`
+> means the current user isn't mapped yet. If the connection mapped on **SAML NameID** instead of Email,
+> the same requirement applies to that identifier.
+
+## Pick the user(s)
+
+Ask which user(s) should get access. If they want the list, page it — **≤10 users per page**, then ask
+"want to see more?" before the next page:
+
+```text
+mcp__headless-360__dispatch_readonly(
+  method: "GET", url: "/services/data/v67.0/query",
+  queryParams: { "q": "SELECT Id, Name, Username, Email FROM User WHERE IsActive = true ORDER BY Name LIMIT 10 OFFSET <page * 10>" }
+)
+```
+
+**Verified gotcha:** early pages are often dominated by non-employee system/integration accounts
+(`Automated Process`, `Bot User`, `Insights Integration`, `*.ext`, `ESW_*` / `*Site Guest User`,
+`DigitalAgent.*`). Do **not** classify rows by eye. Save the response to a file and let the helper
+script tag each row `employee`/`system` deterministically **without dropping any row**:
+
+```text
+node scripts/classify-user-access.mjs flag-users <captured-users.json>
+```
+
+Prints `{users:[{id,name,username,email,kind}], employeeCount, systemCount}`. Present `employee` rows
+first; surface `system`-tagged rows as "these look like system/integration accounts" rather than hiding.
+
+## Look up the permset Id and assign
+
+```text
+mcp__headless-360__dispatch_readonly(
+  method: "GET", url: "/services/data/v67.0/query",
+  queryParams: { "q": "SELECT Id, Name, Label FROM PermissionSet WHERE Name = 'EmployeeSlackNotifications'" }
+)
+```
+
+Then assign to each confirmed user (one record per user):
+
+```text
+mcp__headless-360__dispatch(
+  method: "POST", url: "/services/data/v67.0/sobjects/PermissionSetAssignment",
+  body: { "AssigneeId": "<user id>", "PermissionSetId": "<EmployeeSlackNotifications id>" }
+)
+```
+
+Do **not** read the POST body yourself to decide success. Save it and classify:
+
+```text
+node scripts/classify-user-access.mjs classify-assignment <captured-response.json>
+```
+
+Prints `{status, retryable, message}` where `status` is `success` / `wrong-license` / `other-error`;
+`retryable` is always `false`. Relay the plain-language `message`; never surface the raw error code.
+Optionally verify a `success`: `SELECT Id FROM PermissionSetAssignment WHERE AssigneeId = '<user id>'
+AND PermissionSetId = '<permset id>'`.
+
+> **License gotcha (`wrong-license`):** a Slack permission set can carry a permission-set license only
+> some user licenses can hold. Assigning to an incompatible license fails `400 FIELD_INTEGRITY_EXCEPTION`
+> (*"…user license doesn't support it"*). Observed live: a **Unified Employee** license user was rejected
+> against a Slack PSL; a **Standard User** succeeded (`201`). `EmployeeSlackNotifications` is backed by
+> `EmployeeSlackNotificationsPsl` — its cross-license compatibility wasn't separately verified, so treat
+> any `wrong-license` as authoritative. It is **not** transient — pick a user whose license supports it
+> (or add the PSL), don't retry.
+
+> **API Enabled + agent access (assign here too).** Beyond notifications, this step also grants:
+> **API Enabled** — needed for the Slack/employee app to call Connect APIs on the user's behalf. This is
+> the *API Enabled* system permission carried by a permission set. **Reuse an existing API-Enabled permset
+> if the org already has one** (discover it — query below — don't assume any particular one exists). If none
+> exists, **create one** — a minimal `PermissionSet` with `PermissionsApiEnabled = true` (e.g. Name
+> `Slack_ApiAccess`, label "Slack API Access"). Discover first, create only if none is found, then assign.
+> Also — only for users who will reach the Agentforce agent in Slack — the **per-agent `Agent_Access`**
+> permset carrying that agent's `BotDefinition` `SetupEntityAccess` grant. Discover `Agent_Access` by
+> reverse-lookup on the BotDefinition and create it if absent (mechanics: `connect-agentforce-to-slack.md`);
+> **never** assign the broad `Access_Agents` — it fails on an employee license (*"View Setup Audit Trail"*).
+>
+> **Discover an API-Enabled permset (reuse before create):**
+> ```text
+> mcp__headless-360__dispatch_readonly(
+>   method: "GET", url: "/services/data/v67.0/query",
+>   queryParams: { "q": "SELECT Id, Name, Label FROM PermissionSet WHERE PermissionsApiEnabled = true AND IsCustom = true" }
+> )
+> ```
+> If a row comes back, reuse it — assign it. If none, create one via
+> `POST /services/data/v67.0/sobjects/PermissionSet` with `{ "Name": "Slack_ApiAccess", "Label":
+> "Slack API Access", "PermissionsApiEnabled": true }`, then assign the returned Id.
+
+> **Record visibility — always assigned, one of the three core permsets.** For a UEL employee to actually
+> see records (not just notifications) in the Slack Salesforce app, assign **`ItsmPortalUelUserPermset`**
+> ("ITSM Portal Uel User") — it grants **read/create/edit on Incident, Service Request, and Case** (the
+> self-service scope), alongside an API-Enabled permset. **Always assign it** (with the other two core
+> permsets) to each confirmed user — do **not** offer a "notifications-only" scope; under-assigning
+> silently leaves the employee unable to see records. This deliberately does **not** include **Problem** or
+> **Change Request** — those are fulfiller/manager queues and their Slack lists staying empty ("Nothing
+> turned up") is expected for a self-service employee, not a bug. If a specific user genuinely needs
+> Problem/Change visibility, that is a separate fulfiller-side grant (e.g. `IncidentManager`), handled
+> outside this self-service flow — do not assign it. Full mechanics: `references/record-visibility.md`.

package/skills/service-itsm-slack-itservice-configure/references/record-visibility.md

@@ -0,0 +1,78 @@
+# Record visibility — let a UEL employee view their Incident / Service Request / Case records in Slack
+
+Record visibility is part of the baseline employee role — **always** grant it during Step 4 (it's one of
+the three core permsets) so a Unified Employee (UEL) user can **view and work Incident, Service Request,
+and Case records** (the self-service ITSM entities) in the Slack Salesforce app (e.g. in the Salesforce
+**List views**). It goes beyond the literal Go-page "Manage User Access" click but is what makes the ITSM
+experience actually usable in Slack — say so when you assign it.
+
+> **Always assign — no scope choice.** Assign this to every confirmed user alongside the other two core
+> permsets; do **not** offer a "notifications-only" option. Under-assigning silently leaves the employee
+> able to receive notifications but unable to open the records those notifications point to.
+
+> **Scope note — this is a self-service employee grant, not a fulfiller grant.** The employee gets
+> **Incident + Service Request + Case** (read/create/edit) so they can log and track their own issues and
+> raise service requests. It does **not** include **Problem** or **Change Request** — those are
+> fulfiller/manager queues, out of scope for a self-service employee on Slack. If a specific user genuinely
+> needs Problem/Change visibility, that is a separate fulfiller-side grant (e.g. `IncidentManager`), handled
+> outside this self-service flow — do not assign it by default here.
+
+## Why `EmployeeSlackNotifications` alone isn't enough
+
+- **`EmployeeSlackNotifications`** (Step 4) only grants notification receipt — **no object access**.
+
+So a UEL user assigned only `EmployeeSlackNotifications` will get **"Nothing turned up"** when they open
+the Incident / Service Request / Case lists in Slack. The list *definitions* still appear in the picker
+(they are org-shared metadata), but they return no records without object read.
+
+## What to assign for record visibility
+
+Two things, both assigned to the specific UEL user (never "all active users"):
+
+1. **API Enabled** — required for the Slack/employee app to call Connect APIs on the user's behalf.
+   Any permission set that enables the **API Enabled** system permission works. **Reuse** an existing
+   API-Enabled permset if the org already has one (confirm the user has it before adding); otherwise
+   **create** a Slack-named one (e.g. Name `Slack_ApiAccess`, label "Slack API Access", with
+   `PermissionsApiEnabled = true`).
+2. **`ItsmPortalUelUserPermset`** ("ITSM Portal Uel User") — the standard ITSM self-service permset that
+   grants **read/create/edit on Incident, Service Request, and Case** (plus read on supporting objects
+   like Account, Contact, Asset, and Service Catalog items). This is the correct baseline for a
+   self-service employee — it deliberately does **not** grant Problem or Change Request.
+
+## How to assign (headless-360, one record per user/permset)
+
+Resolve the `ItsmPortalUelUserPermset` Id fresh (stable per org, but don't hardcode); resolve or create
+the API-Enabled permset per the reuse-or-create flow above and use its Id too:
+
+```text
+mcp__headless-360__dispatch_readonly(
+  method: "GET",
+  url:    "/services/data/v67.0/query",
+  queryParams: { "q": "SELECT Id, Name, Label FROM PermissionSet WHERE Name = 'ItsmPortalUelUserPermset'" }
+)
+```
+
+Assign each to the confirmed user (two POSTs — skip either permset the user already has, checked via
+`PermissionSetAssignment`):
+
+```text
+mcp__headless-360__dispatch(
+  method: "POST",
+  url:    "/services/data/v67.0/sobjects/PermissionSetAssignment",
+  body:   { "AssigneeId": "<user id>", "PermissionSetId": "<permset id>" }
+)
+```
+
+Verify (each self-service object should read RCE for Incident/ServiceRequest/Case):
+
+```text
+mcp__headless-360__dispatch_readonly(
+  method: "GET",
+  url:    "/services/data/v67.0/query",
+  queryParams: { "q": "SELECT SobjectType, PermissionsRead, PermissionsCreate, PermissionsEdit FROM ObjectPermissions WHERE ParentId IN (SELECT PermissionSetId FROM PermissionSetAssignment WHERE AssigneeId = '<user id>') AND SobjectType IN ('Incident','ServiceRequest','Case')" }
+)
+```
+
+Then tell the user to reload the Slack Salesforce app; the Incident / Service Request / Case lists that
+previously returned "Nothing turned up" will now resolve records. (Problem and Change Request remain empty
+by design — they are fulfiller queues, not part of the self-service scope.)

package/skills/service-itsm-slack-itservice-configure/references/site-membership-verification.md

@@ -0,0 +1,126 @@
+# Site publish + membership verification (Step 5b)
+
+Setting the **Preferred Digital Experience Site** (`SLACK_PREFERRED_SITE`) and assigning the Step 4
+permission sets are necessary but **not sufficient** for an employee to actually see IT Service records in
+the Slack app. Three silent gaps remain — each of which lets every low-level write return `200`/`201` while
+the end result is still broken. **Verify them separately — they are three distinct states, not one:**
+
+- **(a) activation** — the preferred site (its **`Network`**) is not **`Live`** — a portal in
+  `UnderConstruction` (or `DownForMaintenance`) serves nothing to employees;
+- **(b) membership** — the target employee is **not a `NetworkMember`** of that site — a non-member can't
+  see the portal's records even when the site is Live; and
+- **(c) publication** — the site's **Builder pages are unpublished**. Activation (`Network.Status = 'Live'`)
+  and publication are **separate go-live states**: a Live network with unpublished pages still 404s / shows
+  "under construction". `Network.Status` does **not** prove the pages were published.
+
+On any org where the portal hasn't been activated/published or the user's profile/permset isn't on the
+site's Members list, the Slack "IT Service" record lists come back **empty / access-denied** — yet no
+permset assignment failed, no org preference is wrong, and the Slack connection is fine. So the skill's
+terminal "setup complete" message is materially wrong. **Run all three checks after Step 5 and before any
+success summary; a failure of any one is a blocking finding.**
+
+> **Programmatic remediation exists — this is not UI-only.** Activation and membership go through the
+> **Metadata API** (`Network` status → `Live`; `NetworkMemberGroup` for members) and publication goes
+> through the **community-publish** step `experience-portal-create` owns — there is no Connect API for any of them (a `PATCH /connect/communities/<id>`
+> returns 405). These are the same verified paths `experience-portal-create` uses in its Step 3
+> (Activate → Add Members → Publish); hand the remediation to that skill rather than treating it as a
+> manual builder-only action. Builder clicks are only the fallback when the operator prefers the UI.
+
+## Check (a) — the preferred site is Live
+
+The site Id to check is whatever `SLACK_PREFERRED_SITE` resolves to (read it back in Step 5.2) — a
+`Network` Id (`0DB...`).
+
+```text
+mcp__headless-360__dispatch_readonly(
+  method: "GET",
+  url:    "/services/data/v67.0/query",
+  queryParams: { "q": "SELECT Id, Name, Status FROM Network WHERE Id = '<preferred site Network Id>'" }
+)
+```
+
+- **`Status = 'Live'`** → published; check passes.
+- **Anything else** (`UnderConstruction`, `DownForMaintenance`) → **blocking**. Surface it in plain
+  language — "the employee portal *\<Name\>* isn't published yet, so employees won't see anything in Slack
+  until it's live" — and give the remediation below. Do **not** report setup complete.
+
+### Remediation — activate the Network (programmatic path preferred)
+
+`Network.Status` is not writable through the org-values or a direct SObject/Connect `PATCH` here (a
+`PATCH /connect/communities/<id>` returns **405**). The **verified programmatic path is a Metadata-API
+`Network` deploy** setting `<status>Live</status>` — the same activation step `experience-portal-create`
+runs in its Step 3. **Hand activation to `experience-portal-create` (Activate → Add Members → Publish)**;
+that skill owns the `Network` metadata deploy and the reachability check. After it activates, re-run
+check (a) to confirm `Status = 'Live'`.
+
+Builder fallback (only if the operator prefers the UI): **Digital Experience Builder → open the site →
+Publish** — but note that clicking Publish in the builder both activates *and* publishes, whereas the
+programmatic path treats them separately (check (c)). Don't claim an API activated it if you handed it off
+to the UI. (If the org needs the portal *created* in the first place, that is also the
+`experience-portal-create` hand-off from Step 3, not this check.)
+
+## Check (b) — the target user is a site member
+
+For **each** user assigned in Step 4 (the same confirmed employee user Ids):
+
+```text
+mcp__headless-360__dispatch_readonly(
+  method: "GET",
+  url:    "/services/data/v67.0/query",
+  queryParams: { "q": "SELECT Id FROM NetworkMember WHERE NetworkId = '<preferred site Network Id>' AND MemberId = '<user Id>'" }
+)
+```
+
+- **≥1 row** → the user is a member; check passes for that user.
+- **`0` rows** → **blocking** for that user. Surface it — "\<user\> isn't a member of the *\<Name\>*
+  portal, so they won't see IT Service records in Slack" — with the remediation below.
+
+`NetworkMember.MemberId` is the `User` Id. Membership is usually granted **by profile or permission set**
+(the site's Members list), not per-user — so one fix typically covers many users at once.
+
+### Remediation — add members (programmatic path preferred)
+
+`NetworkMember` is not directly writable through a public Connect/SObject write here, but membership **is**
+grantable programmatically: adding a **Profile** or **permission set** to the site's Members list is a
+**Metadata-API `NetworkMemberGroup`** deploy — the same "Add Members" step `experience-portal-create` runs
+in its Step 3. **Hand membership to `experience-portal-create`**, which owns the `NetworkMemberGroup`
+metadata (with its column discipline). Adding a profile/permset covers all users who hold it at once.
+
+Builder fallback (only if the operator prefers the UI): **Experience Builder → open the site →
+Administration → Members** → add the employee's **Profile** (or a **permission set** the employee holds) to
+the *Selected* Members list → **Save**.
+
+After membership is granted, re-run check (b) for the affected user(s) to confirm a `NetworkMember` row now
+exists. Don't claim an API added the member if you handed it off to the UI.
+
+## Check (c) — the site's Builder pages are published
+
+Activation (check (a)) makes the `Network` addressable; it does **not** publish the Builder pages. A Live
+network whose pages were never published still serves "under construction" / 404s, so employees see nothing
+in Slack. Publication is a **separate go-live mutation** and must be verified on its own.
+
+There is no `Network` column that cleanly reports "pages published," so verify publication the way
+`experience-portal-create` does — confirm the site is reachable end to end after a publish, and treat a
+never-published site (one that has only ever been activated) as **not published**:
+
+- If the site was provisioned/activated but the **community-publish step has never completed** for it →
+  **blocking**. Surface it — "the employee portal *\<Name\>* is active but its pages aren't published yet,
+  so employees will see 'under construction' in Slack" — with the remediation below.
+
+### Remediation — publish the site (programmatic path preferred)
+
+Publication has **no Connect API**; the verified path is the community-publish CLI step, polled to
+completion on `BackgroundOperation` — exactly `experience-portal-create`'s Step 3 "Publish" step. **Hand
+publication to `experience-portal-create`**; it publishes the site by name against the org and waits for
+the returned `jobId` to reach `Status: Complete`.
+
+Builder fallback (only if the operator prefers the UI): **Digital Experience Builder → open the site →
+Publish**. After publication completes, re-confirm reachability. Don't claim an API published it if you
+handed it off to the UI.
+
+## Reporting
+
+Only after **all three** checks — (a) activation, (b) membership, (c) publication — pass for the chosen site
+and every Step-4 user may the skill proceed to Step 6 (or emit the success summary). If any check fails, the
+user-facing message must name the specific blocking finding(s) and the remediation (prefer the
+`experience-portal-create` programmatic hand-off; UI as fallback) — not a green "setup complete."

package/skills/service-itsm-slack-itservice-configure/scripts/classify-user-access.mjs

@@ -0,0 +1,167 @@
+#!/usr/bin/env node
+// Deterministic helpers for Step 4 (Manage User Access) of the Slack Employee
+// Service setup, so the model never eyeballs a response body.
+//
+// Two sub-commands:
+//
+//   flag-users <users-query.json>
+//     Reads the User SOQL response (the {records:[...]} envelope from
+//     /services/data/vXX.0/query) and tags each row as "employee" or "system"
+//     using a fixed heuristic — WITHOUT dropping any row. System/integration
+//     accounts (Automated Process, Bot User, Insights Integration, *.ext,
+//     ESW_* / *Site Guest User, DigitalAgent.*, *@00d* platform users) are
+//     flagged so the user isn't asked to guess, but they are still listed.
+//     Prints {users:[{id,name,username,email,kind}], employeeCount, systemCount}.
+//
+//   classify-assignment <assignment-response.json>
+//     Reads the PermissionSetAssignment POST result and classifies it as
+//     "success" (201 / has an id), "wrong-license" (a 400
+//     FIELD_INTEGRITY_EXCEPTION about the Slack permission-set license not
+//     being supported by the user's license — a HARD stop, do not retry), or
+//     "other-error". Prints {status, retryable, message}.
+//
+// Both read their input from a file path (pass the captured response JSON).
+// Exits 2 on missing/bad args, 3 on unreadable/unparseable input.
+
+import { readFileSync } from 'node:fs';
+
+const [cmd, inPath] = process.argv.slice(2);
+
+// headless-360 `dispatch`/`dispatch_readonly` may hand back either the raw
+// Salesforce payload or an envelope like { status_code, body } / { statusCode,
+// body } / { data }. Unwrap to the underlying Salesforce payload so both the
+// user-query and the assignment-response classifiers see the shape they expect
+// regardless of how the response was captured. (Idempotent: a raw payload with
+// no envelope key is returned unchanged.)
+function unwrapEnvelope(data) {
+  if (data && typeof data === 'object' && !Array.isArray(data)) {
+    const hasEnvelopeMarker =
+      'status_code' in data || 'statusCode' in data || 'httpStatusCode' in data;
+    if (hasEnvelopeMarker && data.body !== undefined) return data.body;
+    // A lone { data: ... } wrapper (no status marker) is also an envelope.
+    if (
+      data.body === undefined &&
+      data.data !== undefined &&
+      !('records' in data) &&
+      !('id' in data) &&
+      !('Id' in data)
+    ) {
+      return data.data;
+    }
+  }
+  return data;
+}
+
+function die(code, msg) {
+  process.stderr.write(`${msg}\n`);
+  process.exit(code);
+}
+
+function loadJson(path) {
+  if (!path) die(2, 'usage: node classify-user-access.mjs <flag-users|classify-assignment> <response.json>');
+  let raw;
+  try {
+    raw = readFileSync(path, 'utf8');
+  } catch {
+    die(3, `error: could not read ${path}`);
+  }
+  try {
+    return JSON.parse(raw);
+  } catch {
+    die(3, `error: could not parse JSON in ${path}`);
+  }
+}
+
+// A row is a system/integration account (flag, don't drop) if its Name or
+// Username matches any of these fixed patterns. Case-insensitive.
+const SYSTEM_NAME_PATTERNS = [
+  /^automated process$/i,
+  /^bot user$/i,
+  /insights? integration/i,
+  /integration user/i,
+  /site guest user/i,
+  /^chatter expert$/i,
+  /^security user$/i,
+  /^analytics cloud/i,
+  /platform integration user/i,
+];
+const SYSTEM_USERNAME_PATTERNS = [
+  /\.ext@/i, // *.ext users
+  /^esw_/i, // ESW_* embedded-service users
+  /^digitalagent\./i, // DigitalAgent.* agent users
+  /@00d/i, // *@00d... platform/site users
+  /autoproc@/i,
+  /insightssecurity@/i,
+];
+
+function classifyUserKind(name, username) {
+  const n = String(name ?? '');
+  const u = String(username ?? '');
+  const isSystem =
+    SYSTEM_NAME_PATTERNS.some((re) => re.test(n)) ||
+    SYSTEM_USERNAME_PATTERNS.some((re) => re.test(u));
+  return isSystem ? 'system' : 'employee';
+}
+
+function flagUsers(data) {
+  const records = Array.isArray(data?.records) ? data.records : Array.isArray(data) ? data : [];
+  const users = records.map((r) => {
+    const kind = classifyUserKind(r?.Name, r?.Username);
+    return {
+      id: r?.Id ?? null,
+      name: r?.Name ?? null,
+      username: r?.Username ?? null,
+      email: r?.Email ?? null,
+      kind,
+    };
+  });
+  const employeeCount = users.filter((u) => u.kind === 'employee').length;
+  const systemCount = users.length - employeeCount;
+  return { users, employeeCount, systemCount };
+}
+
+// Salesforce error responses come back as an array of {errorCode, message} or
+// a single object; normalize and classify.
+function classifyAssignment(data) {
+  // Success shapes: {id, success:true} (sObject POST) or {Id: "0Pa..."}.
+  const id = data?.id ?? data?.Id ?? null;
+  if (id && data?.success !== false) {
+    return { status: 'success', retryable: false, message: 'Permission set assigned.' };
+  }
+
+  const errors = Array.isArray(data) ? data : Array.isArray(data?.errors) ? data.errors : [data];
+  const first = errors.find((e) => e && (e.errorCode || e.message)) ?? {};
+  const errorCode = String(first.errorCode ?? '');
+  const message = String(first.message ?? '');
+
+  const looksLikeLicenseMismatch =
+    /FIELD_INTEGRITY_EXCEPTION/i.test(errorCode) &&
+    /(permission set license|user license)/i.test(message) &&
+    /(support|assigned)/i.test(message);
+
+  if (looksLikeLicenseMismatch) {
+    return {
+      status: 'wrong-license',
+      retryable: false,
+      message:
+        "This user's license can't hold this permission set. Pick a user on a compatible " +
+        'license (a Standard User works) rather than retrying.',
+    };
+  }
+
+  return {
+    status: 'other-error',
+    retryable: false,
+    message: message || errorCode || 'Assignment failed for an unknown reason.',
+  };
+}
+
+const data = unwrapEnvelope(loadJson(inPath));
+
+if (cmd === 'flag-users') {
+  process.stdout.write(JSON.stringify(flagUsers(data), null, 2) + '\n');
+} else if (cmd === 'classify-assignment') {
+  process.stdout.write(JSON.stringify(classifyAssignment(data), null, 2) + '\n');
+} else {
+  die(2, 'usage: node classify-user-access.mjs <flag-users|classify-assignment> <response.json>');
+}