Multi-Project Setup

Multi-project setup

Most organizations support more than one product. Auxilium’s project model lets you run isolated support streams – each with its own channels, SLA policies, tags, and customer portal – while sharing a single agent pool and customer database.

When to use multiple projects

A single project works when you have one product with a unified support experience. Multiple projects become valuable when:

Different products have different SLA targets. An infrastructure product may require a 15-minute first response; a consumer app may allow 4 hours.
Different teams own different products. Engineering handles the API platform while Customer Success handles the onboarding tool. Each team wants its own ticket queue.
Customers expect separate portals. Each product has its own brand, domain, and self-service portal.
Channel configurations differ. Product A uses email and Slack; Product B uses email and WhatsApp.

Example: three-product organization

Consider a company with three products: CloudStore (e-commerce platform), MobileApp (consumer mobile application), and AdminPanel (internal tools).

Tenant: Acme Corp
  |
  +-- Project: CloudStore
  |     Channels: Email, Web Widget, Slack
  |     SLA: First response 1 hr, Resolution 24 hrs
  |     Portal: support.cloudstore.com
  |
  +-- Project: MobileApp
  |     Channels: Email, WhatsApp, Apple Messages
  |     SLA: First response 4 hrs, Resolution 48 hrs
  |     Portal: help.mobileapp.com
  |
  +-- Project: AdminPanel
        Channels: Email, Microsoft Teams
        SLA: First response 30 min, Resolution 8 hrs
        Portal: support.adminpanel.internal

To set this up, navigate to the Projects page and click Add Project three times, creating one project for each product with its own name, slug, and description. After creating the projects, configure each one independently with its own channels, SLA policies, and portal settings.

What gets scoped to each project

Every project maintains its own isolated set of resources:

Resource	Scoping behavior
Tickets	A ticket belongs to exactly one project. Agents see project-specific queues.
Channels	Each project configures its own email inboxes, web widgets, Slack channels, etc.
Tags	Classification tags are defined per project, so “billing-issue” in CloudStore is separate from “billing-issue” in MobileApp.
SLA policies	Response and resolution targets are set independently per project.
Customer portal	Each project can have its own branded, white-labeled portal.

Meanwhile, these resources are shared across all projects:

Resource	Scoping behavior
Agents	All agents can work tickets in any project. Access is controlled by role, not project.
Customers	A customer exists once and can submit tickets to any project.
Departments	Organizational structure spans the entire tenant.

Agent access

All agents in a tenant can access all projects. There is no project-level agent restriction – access control is managed through roles (Admin, Manager, Agent), not project membership.

Cross-project dashboard views

The dashboard supports both tenant-wide and project-scoped views. Use the project selector at the top of the dashboard to switch between them:

View	How to access	Best for
Tenant-wide	Leave the project selector on “All Projects”.	Operations managers monitoring overall health across all products.
Project-scoped	Select a specific project from the selector.	Team leads focused on a single product’s metrics.

The tenant-wide view aggregates KPIs, channel breakdowns, and SLA alerts across all active projects. Switch to the project-scoped view when diagnosing issues or reviewing performance for a specific product.

Planning your project structure

Before creating projects, consider these questions:

Question	Guidance
Do the products have different SLA requirements?	Separate projects let you define independent SLA policies for each.
Do different teams own different products?	Separate projects give each team a focused ticket queue.
Do customers need separate portals?	Each project gets its own portal with independent branding.
Do the products use different support channels?	Channel configuration is per-project, so separate projects keep things clean.
Is it one product with multiple modules?	A single project with tags for each module may be simpler than multiple projects.

Avoid over-segmentation

Creating too many projects adds operational overhead. If two products share the same SLA targets, channels, and support team, they may be better served as a single project with tags to differentiate them.