Launchpad CRS role-name compatibility

Jira: BIF-9001 · implementation Task BIF-8906 · Epic: BIF-8695

Overview

The upstream CRS access-management contract now validates company-role names against client_id/company_sso_id and requires the shape {APPLICATION_NAME}_{DEFAULT|CUSTOM}_{CUSTOM_NAME}. Launchpad's raw custom role names can therefore be rejected when a company role is created or edited. This is an upstream contract compatibility change, not a request to rename the values that Launchpad stores or exposes.

The incident thread also reported that some Qontak One clients created after 2026-07-17 could fail login and consultant mode while the change was being rolled out. A rollback and data backfill were requested, but the supplied thread ends before final verification. The formatter must therefore be safe to roll out behind a toggle and must not hide CRS errors.

No Product Intelligence Hub checkout was available during authoring; sources: [] records that evidence gap explicitly.

Scope Changes

• Backend — format only the CRS-bound company-role create/edit payloads and retain raw values everywhere Launchpad owns the role name.

Goals

• Make CRS-bound custom company-role create and edit requests conform to the upstream role-name contract, using the agreed application name and identifiers.
• Preserve the raw role name in Launchpad storage, local/API responses, audit records, and Loyalty integrations.
• Allow the compatibility behavior to be enabled or disabled without a redeploy while the upstream contract is being confirmed.

Non-goals

• Renaming or migrating raw role names in Launchpad databases, APIs, audit logs, or Loyalty.
• Changing default-role semantics or unrelated read paths.
• Deciding the upstream application's canonical name, identifier source, or backfill execution beyond documenting the required coordination.

8. User Stories + Acceptance Criteria

User Story	Importance	Mockup / Technical Notes	Acceptance Criteria
[ROLENAME-S01] — Keep CRS company-role names contract-compatible As a Launchpad operator, I want company-role create and edit requests translated to the CRS role-name contract, so that new and existing clients can authenticate and use consultant mode without changing their Launchpad-visible role names.	Must Have	Implementation Task BIF-8906. Apply one formatter at the two intended CRS-bound write paths; use the confirmed application name and client_id/company_sso_id mapping.	— Happy Path — • AC-1: Given a custom company role is created, when Launchpad sends the CRS request, then the outbound role name follows {APPLICATION_NAME}_CUSTOM_{CUSTOM_NAME} (for example Qontak_Custom_<raw_name>) and the request uses identifiers consistent with client_id/company_sso_id. • AC-2: Given an existing custom company role is edited, when Launchpad sends the CRS request, then the same formatting and identifier consistency rules apply. • AC-3: Given a successful create or edit, when Launchpad returns or records the role, then the raw input remains unchanged in Launchpad storage, local/API responses, audit records, and Loyalty integrations. • AC-4: Given the feature toggle is disabled, when a write is attempted, then formatting is bypassed and the prior behavior is retained without a redeploy. — Error / Unhappy Path — • ERR-1: Given CRS rejects a formatted request, when Launchpad receives the response, then it surfaces the failure using the existing error path and does not report a false success or silently mutate the stored raw name. — Guard-rail — • NEG-1: Given unrelated read paths, default roles, or non-company role consumers, when they run, then their role-name behavior is unchanged and the formatter is not applied a second time. • NEG-2: Given a newly created client after rollout, when login and consultant mode are exercised, then both flows succeed and the compatibility formatter introduces no authentication regression.

Incident evidence and recovery

An upstream validation change was observed in staging, followed by reports of login and consultant-mode failures for newly created clients. A rollback was requested and a same-day backfill/retest was planned. The available conversation does not confirm the final result, so production verification remains an explicit follow-up rather than an assumed completion.

Open questions

1. What exact APPLICATION_NAME and casing are authoritative for CRS, and how is it derived from client_id/company_sso_id?
2. Should an already-prefixed input be passed through, or normalized before the formatter runs?
3. Which client IDs and role records require backfill, and who owns the backfill verification?
4. What staging and production smoke checks are required for login, consultant mode, and role create/edit before enabling the toggle by default?