Use Divisions to organize support work, defaults and deliberate access

Divisions give Supportbench an organizational context for support work, such as Product Support and Billing. They can help align case forms, reporting, default reply addresses, knowledge defaults and relevant asset categories. They are useful when teams share customer relationships but need different operating arrangements. Creating or naming a Division does not by itself establish every permission, queue, workflow or customer-portal boundary.

Choose a Division for an operational reason  ·  Create or update a Division  ·  Understand defaults and hierarchy  ·  Separate the agent’s Division from Role access  ·  Verify customer visibility separately  ·  Coordinate Divisions with case policies, queues and workflows  ·  Example: Product Support and Billing share one customer relationship  ·  Change or retire a Division with dependent work in mind  ·  Troubleshoot Division behavior

Choose a Division for an operational reason

Prefer a structure people can explain consistently. Creating a separate Division for every customer can complicate roles, reporting and maintenance when Company relationships already describe the customer. Use a Division when the operating model actually differs, and document the reason before multiplying configuration.

Create or update a Division

1. Open Settings → Organization → Divisions. You need Administer divisions permission. Choose New Division or open the intended existing record.
2. In Division Profile, enter Name (up to 50 characters) and Description (up to 250 characters). Describe the work, not only an internal abbreviation.
3. Choose Parent division when applicable. A blank parent is a Root division; a child can be linked under a root. Do not design an arbitrary multi-level hierarchy from old examples.
4. Set Display order; lower values appear earlier. Use an order that supports common agent tasks.
5. Under Defaults & Linking, choose the appropriate Default email, Default KB community and Asset categories. Review each choice below.
6. Under Status, set Active division according to whether the Division should be available for active selection/routing.
7. Choose Save Changes. Reopen the record to confirm the values, then verify affected case forms, defaults and access through the intended workflow.

Understand defaults and hierarchy

After a change, the affected lists and defaults can refresh through application caches. Reopen the relevant workspace and verify the intended result. Do not repeatedly alter values while an earlier save or refresh outcome is still uncertain.

Separate the agent’s Division from Role access

An agent profile has both Division and Role. The profile Division is the primary organizational context used to align assignment and category visibility. The Role defines permissions and the allowed Division scope. These controls have different jobs; changing the primary Division alone is not a complete access configuration.

1. Open Settings → Organization → Roles using an administrator with Administer agent roles permission.
2. Open the intended Role and inspect its Divisions selection. Choose the deliberate subset required for that Role.
3. Review other Role permissions alongside the scope. A Division selection is not an action permission such as editing or administering records.
4. Save through the Role workflow, then verify the intended agent has that Role and the appropriate profile Division.
5. Use representative permitted and forbidden records to confirm the result under that agent’s authorized identity. Check the actual task paths, not only whether a list looks shorter.

Verify customer visibility separately

Customer access is determined through the customer portal, Contact/Company relationships, customer roles and relevant article/case restrictions. A Division name such as “Private,” “Finance” or a customer’s brand does not automatically enforce an end-to-end boundary. Verify the actual access rules instead of relying on the label.

For knowledge, the portal’s Division/category scope and descendants, customer roles, tags/assets, public topic state and article access can all participate. Default KB community selects a default context; it does not make an internal article public. Similarly, moving a case between Divisions must be reviewed with the intended agent and customer visibility rules.

When designing a multi-brand service, agree which organization/person owns each case, which agents can work it, which reply address should be used, and which portal audience should find the corresponding knowledge. Test these separately. A visually correct brand or topic menu is not proof of the underlying record access.

Coordinate Divisions with case policies, queues and workflows

A case’s Division can influence which form and default context applies, but its Queue or assigned agent remains a separate field. Do not assume that creating a Division automatically creates a queue or that selecting the Division always routes the case to a particular team. Review the configured workflow actions and the final saved case.

• Confirm the relevant Case Policies expose and require the right fields for the work.
• Check active queue and workflow rules that inspect or change Division. Keep the intended owner/queue and customer update responsibility clear.
• Review shared and scheduled views so their Division filters match the intended reporting scope.
• Check the default reply identity and relevant asset choices in an actual permitted workflow.
• Review knowledge defaults and customer-portal access independently.
• Update the team’s operating instructions when a Division or its purpose changes.

Example: Product Support and Billing share one customer relationship

A business customer reports an integration failure while its finance team also asks about an invoice. Product Support and Billing may need different fields, reply defaults and reporting. The same Company relationship can provide customer context while separate cases follow the appropriate operational process.

Create the Divisions for those distinct kinds of work, configure the relevant forms/defaults, and define which Roles can access each. Route cases through the intended queues/workflows. If a specialist needs to assist on the other team’s case, use the approved collaboration and access process rather than assuming every employee should see both Divisions.

For a cross-team escalation, name the owner who keeps the customer informed and record the dependency. A Division change is a classification/context change; it is not a complete handoff by itself. Review the saved ownership, active service targets and customer-facing communication afterward.

Change or retire a Division with dependent work in mind

Before changing hierarchy, defaults or Active division, identify existing cases, policies, queues, workflows, forms, views, knowledge defaults and linked assets that depend on it. Agree where ongoing work should remain visible and who will maintain the replacement configuration.

Use inactivation only after reviewing the effect on the Division and its children. The deletion dialog warns that deletion is irreversible; do not present deletion as a normal housekeeping step for a Division that has meaningful history or dependencies. This guide does not instruct you to delete a Division as part of setup.

Record the intended change and verify representative workflows after saving and refreshing. Keep operational labels stable where practical so agents and reports do not lose a familiar meaning without an explanation.

Troubleshoot Division behavior

Continue learning

• Reference Division configuration settings
• Configure agent roles and permissions
• Configure Case Policies
• Build operational views
• Maintain customer Company and Contact relationships
• Separate portal sign-in from customer access