Team & permissions

Comers separates a person’s identity from the access they have inside a business.

Signing in establishes who the person is. Organization membership, business scope, and permissions determine what that person can see and do.

This distinction makes it possible to give a team access to the same Organization without giving every person the same operational authority.

flowchart TD
    I[Identity] --> M[Organization membership]
    M --> S[Business scope]
    S --> P[Permissions]
    P --> A[Allowed actions]
    P --> AI[Agent Comers access]

Organization membership

A team member works inside an Organization through explicit membership.

Membership connects the person’s Comers identity with that Organization. It does not automatically grant access to every other Organization that exists in Comers.

The same person can belong to more than one Organization when they have been granted membership in each one.

When switching between Organizations, the available data and actions follow the selected business context.

Business scope

Access can be narrower than the whole Organization.

Depending on the configured permissions and product area, a person’s access can be limited to the business context they need, such as particular Sellers, sales-channel accounts, modules, or operations.

This matters when one Organization manages several brands, stores, or operational teams.

For the structure these scopes refer to, see Business structure.

Permissions control actions

Being able to see an area does not necessarily mean being able to perform every action in it.

Permissions can distinguish activities such as:

reading operational data,
managing records,
adding comments,
assigning work,
changing configuration,
performing other sensitive actions.

The exact permission set depends on the module and the user’s responsibilities.

Add access according to responsibility

Give a team member the access required for their role rather than granting the broadest possible scope by default.

For example:

a customer-service user may need Messages and Support for selected sales contexts,
a warehouse operator may need inventory and fulfillment-related areas,
a manager may need a broader view across several Sellers,
an organization administrator may need access to configuration and team management.

The exact setup should reflect your organization’s responsibilities rather than forcing every team member into the same access pattern.

Existing Comers identities

If a person already has a Comers identity, that identity can be used with additional Organization memberships instead of treating the person as a completely separate user for every Organization.

The person’s access remains independent in each Organization.

Membership in Organization A does not imply access to Organization B.

Changing or removing access

When a person’s responsibilities change, update or remove the access they no longer need.

Removing future access should not erase the fact that the person previously performed actions in the system. Historical attribution remains useful for operational history and accountability.

For this reason, access management and activity history are separate concerns.

Customer administration and Comers administration

Administration inside your Organization is not the same thing as internal Comers administration.

A customer administrator can manage customer-side capabilities granted to them, but this does not make the person a member of the Comers internal operations or administration team.

Shared sign-in does not collapse these boundaries.

Agent Comers follows the same access

Comers AI and Agent Comers do not give the user additional business permissions.

When the Agent works on behalf of a user, it is constrained by the effective access available to that user.

If a person cannot access a Seller, conversation, Order, or operation normally, using the Agent must not become a way to bypass that restriction.

Organization-specific Business Instructions can further constrain what the Agent should do, but they do not expand the user’s permissions.

Authentication is not authorization

It is useful to keep two concepts separate:

authentication confirms the person’s identity,
authorization determines the Organization, business scope, and operations available to that person.

A successful sign-in therefore does not mean universal access across Comers.

If a user can sign in but cannot enter an expected area or perform an action, check their membership, scope, and permissions rather than assuming the login itself failed.

Recommended approach

When adding or reviewing team access:

confirm the correct Organization,
identify which Sellers or channel contexts the person needs,
grant access only to the modules required for their work,
allow sensitive actions only where the role requires them,
review access again when responsibilities change.

This keeps day-to-day work practical while reducing unnecessary access to business data and operations.