Support

Support is the case-management area for operational issues that need more than a single inbox action.

A Support case gives the issue an owner, status, priority, internal discussion, relationships and history while keeping it connected to the commerce context that caused it.

flowchart TD
    X[Operational issue] --> C[Support case]
    M[Message thread] --> C
    O[Order / shipment context] --> C
    C --> A[Assignment]
    C --> N[Internal comments]
    C --> P[Priority and status]
    A --> R[Resolution]
    N --> R
    P --> R

Support is intended for your organization’s work with its own customers and operations. It is separate from support provided by Comers to Comers customers.

When to use Support

Use a Support case when an issue needs ongoing ownership or coordination.

Typical examples include:

• a customer conversation that cannot be resolved with one reply,
• a shipment problem that needs investigation,
• an Order that requires internal follow-up,
• an operational issue that must be assigned to a person,
• a case where decisions and comments should remain visible as a history.

A normal message thread can remain in Messages when it only needs conversation handling. Move into Support when the issue itself needs to be managed as a case.

Case identity

Each case has a human-facing case number that can be quoted in conversation.

The case number is intended as a convenient reference for people. Internal technical identifiers are not meant to be the identifier users need to communicate verbally or by email.

Status and priority

A Support case has its own operational state and priority.

Use the case status to show where the issue is in its handling lifecycle and the priority to communicate how urgently it should be addressed.

Changing the case state is part of the case history, so Support can preserve how the issue progressed rather than only displaying its latest values.

Assignment and ownership

A case can be unassigned, claimed by a team member, released, or assigned to another permitted person.

The exact assignment actions available to you depend on your permissions.

This allows teams to distinguish:

• work that has not yet been claimed,
• work currently owned by you,
• work assigned to another team member.

Access to a case still depends on the business scope available to the user. Being able to sign in does not grant access to every Support case.

Internal comments

Support comments are used for internal collaboration around the case.

They let the team keep investigation notes, decisions and coordination in the case without mixing every internal discussion into the customer’s conversation.

Comments remain part of the case history and are separate from sending a message to the customer.

Relations and operational context

A Support case can keep relations to the business records that explain why the issue exists.

The exact relationships depend on the workflow. Support is designed to carry commerce context instead of becoming an isolated ticket number with no link back to the operational work.

Creating a case from Messages

A supported workflow allows a readable Message thread to become the source of a Support case.

When you create a case from a conversation, Comers verifies the source thread in the current user’s allowed business context and then creates the case with a relation back to that thread.

If the source conversation is unavailable or outside your permitted scope, the case should not be created from it.

This keeps Support and Messages connected while allowing each module to retain its own responsibility:

• Messages owns the conversation,
• Support owns the operational case.

Case history

Support preserves changes as a history so the team can understand how the case developed.

This includes relevant changes such as assignment, status, priority and other case updates.

Historical attribution remains useful even after a team member’s access later changes.

Permissions

Different Support actions can require different permissions.

For example, the ability to read a case is different from the ability to manage it, comment on it, or assign it to another person.

This follows the wider Comers access principle: identity, organization membership and permissions are separate concerns.

Good practice

Create a Support case when the problem itself needs ownership and resolution, not merely because a customer sent a message.

Keep customer communication in Messages and internal coordination in the Support case. Linking the two gives the team both the original conversation and a clear operational record of what is being done about it.