Give new cases a recognizable prefix through Company customer roles

A recognizable case prefix helps a B2B support team discuss work without losing the customer or service context. For example, an organization might use an agreed prefix for cases associated with a particular customer group. Supportbench can select a Case ID mapping through the Company’s assigned Customer roles when a new case is created. Set up the mapping, role and Company association together, then test a newly created case. A prefix is an identifier convention: it does not by itself assign ownership, grant a service level or restrict who can read the case.

Understand the three parts before changing anything  ·  Choose a convention that helps the operation  ·  Prepare access and the customer-role design  ·  Step 1: create the Case ID mapping  ·  Step 2: connect a Customer role to the mapping  ·  Step 3: associate the role with the Company  ·  Step 4: verify a newly created case  ·  Why an existing case keeps its old prefix  ·  Avoid relying on “the first assigned role”  ·  Troubleshoot the layer that owns the problem

Understand the three parts before changing anything

For an ordinary Supportbench-created case, the prefix appears with its generated case number; an import or integration may supply a different source ID. Keep the complete displayed identifier when referring to a case; a familiar prefix is not a replacement for the case number. The ordinary fallback is the standard Case prefix, commonly displayed as C. These instructions do not create a separate numbering sequence, promise a particular next number or renumber an existing case.

Customer roles and agent roles serve different purposes. An agent role controls staff permissions. This procedure uses Customer roles associated with Companies; it does not give a staff member permission to administer settings or work another Division’s cases.

Choose a convention that helps the operation

Use a custom prefix when people will consistently recognize it and it will remain useful throughout the case’s life. An agreed customer segment or stable account grouping can be useful in an account review, a handoff or a conversation with a service partner. Keep the vocabulary small enough that agents do not need a separate lookup for every case they see.

Prepare access and the customer-role design

1. Agree the proposed prefix and what it means. Prefixes must be nonblank and contain no more than five characters; duplicate or reserved values are rejected. Keep the convention easy to read and communicate.
2. Confirm access to Id mapping through Administer API configurations. Customer roles require Administer company and contact configurations, and editing a Company requires Create and update companies plus access to that record. Seeing one screen does not establish access to all three.
3. Check existing mappings and roles before adding another. Reuse a suitable, correctly scoped definition when that preserves the intended meaning.
4. Review where the proposed Customer role is used for portal or knowledge visibility. Assigning a role for an ID convention can have consequences beyond naming if that role is already referenced by access rules.
5. Choose an approved test Company/Contact and a creation path you can verify without unnecessary customer messages. Review any configured creation notifications before making a live test case.
6. Plan one Case-ID-mapped role per Company. A Company may have other roles, but multiple applicable mapped roles do not provide a dependable priority scheme.

Step 1: create the Case ID mapping

1. Open Settings → API → Id mapping. The navigation label is singular even though the page manages multiple mappings.
2. Choose New mapping.
3. Enter the agreed Prefix, such as ACME. Use an available value of one to five characters. Do not copy the whole example case ID or include the case number in this field.
4. Set Used for to Case. This is the record type for the mapping.
5. Add an optional Description explaining the convention and its intended use; the maximum is 250 characters.
6. Choose Save Changes. Resolve any duplicate, reserved-value or validation message instead of assuming the record was saved.
7. Reopen the mapping and confirm the prefix and record type. Existing mapping prefixes are not editable; the record type also cannot be changed once the mapping is in use.

Treat the prefix as a durable choice. If the business convention changes later, create and review the appropriate replacement mapping rather than expecting an existing prefix to be renamed. Keep historical case identifiers understandable during the transition.

Step 2: connect a Customer role to the mapping

1. Open Settings → Customers → Customer roles.
2. Open an appropriate existing role or choose New Role. Review existing use before repurposing a role.
3. Enter a clear Name, up to 50 characters, and an optional Description, up to 250 characters. Describe the customer grouping in language an account owner will understand.
4. Choose the mapping in Case ID mapping. Confirm that it is the intended Case mapping, not merely a similarly named option.
5. Review Active role and save with Save Changes.
6. Reopen the role and verify the saved mapping. Record any separate portal or knowledge rules that reference this role so a later administrator understands its wider use.

Do not assume that making a role inactive automatically removes every existing Company association or prevents the prefix resolver from using it. When retiring a convention, review and deliberately change the relevant association and mapping, then test the result.

Step 3: associate the role with the Company

1. Find and open the intended Company in the Companies workspace. Check the name and customer context carefully, especially when a parent organization and its subsidiaries have similar names.
2. Open the Company editor and select Roles.
3. Select the intended Customer role. Review the other assigned roles before saving, including whether another role also supplies a Case ID mapping.
4. Save the Company and reopen it to confirm the association.
5. Check that the Contact and Company you will use for case creation represent the intended customer relationship. A similarly named Contact at another Company is not a valid test of this mapping.

For an organization with several Contacts, the Company association provides a consistent customer context for the convention. Do not assume that assigning the role to one Company also assigns it to every parent, subsidiary or related Company; verify each intended record.

Step 4: verify a newly created case

1. Open New Case using an approved test process. Select the intended Company and Contact before creating the case.
2. Review case ownership, queue, first activity and recipients. Follow the Case Add guide so the test does not accidentally send a customer message.
3. Create the case and read its complete displayed ID. Confirm that the expected prefix was applied.
4. Open the saved case and verify its Company, Contact, owner and other required fields. A correct-looking prefix alone does not prove the entire case was created correctly.
5. Test a case for a Company without the mapped role and confirm the intended standard behavior.
6. If your operation also creates cases through email, the portal or an integration, verify each relevant path separately. The Company must be available at the creation decision, and a caller-supplied source prefix may preserve a different identifier.

Keep the test evidence practical: the mapping, role, Company, creation channel, full case ID and observed result. Do not use a saved draft as proof that a final new case received the expected identifier.

Why an existing case keeps its old prefix

Company role mapping is evaluated when creating a case if no source prefix has already been supplied. Associating the Company after creation does not automatically change that case’s identifier. Likewise, changing the Company’s role or its mapping later does not rewrite existing IDs. This preserves the references already used in messages, links and customer conversations.

Do not try to correct a prefix by creating duplicate support cases or manipulating the numeric portion. If a historical identifier causes operational confusion, record the current customer context clearly and use the complete existing ID. Ask Supportbench about a specific exceptional requirement rather than treating this setup as an ID-renaming tool.

Avoid relying on “the first assigned role”

If several roles are operationally necessary, review which ones actually need a Case ID mapping. Other customer classifications can remain useful without defining competing prefixes. Because role assignments may also affect customer-content access, review the wider consequences before removing a role solely to simplify numbering.

After changing the role set, save and reopen the Company, then create a new approved test case. Inspect the resulting identifier instead of assuming the old ambiguity has disappeared because the selection screen looks correct.

Troubleshoot the layer that owns the problem

When escalating a setup issue, provide the full case ID, creation channel, expected prefix, saved mapping and relevant role/Company association. Include the observed result and whether the Company was set before creation. Avoid unnecessary customer message bodies or credentials.

Continue learning

• Reference record ID mapping settings
• Configure Customer roles and their mappings
• Manage Company and Contact relationships
• Create a case with the correct customer context
• Review customer portal access
• Configure actual SLA commitments
• Build views for operational follow-up