Example 1: many-to-one review and SPAM routing
GenEmails supports multiple Original Queues pointing to the same Review Queue and the same SPAM Queue or SPAM table when that is how the tenant wants to centralize triage.
| Original Queue | Review Queue | SPAM Queue | SPAM Table |
|---|---|---|---|
GenEmails_Billing | GenEmails_SHARED_REVIEW | GenEmails_SHARED_SPAM | GenEmails_SHARED_SPAM |
GenEmails_Collections | GenEmails_SHARED_REVIEW | GenEmails_SHARED_SPAM | GenEmails_SHARED_SPAM |
GenEmails_Support | GenEmails_SHARED_REVIEW | GenEmails_SHARED_SPAM | GenEmails_SHARED_SPAM |
This works well when one supervisor team reviews multiple business queues. The main requirement is that the mapped objects remain valid and accessible under the selected tenant's Genesys permissions.
Example 2: cross-division or not-strict mapping
Strict Mapping enforces same-division routing objects. If a tenant intentionally wants an Original Queue in Division A to use a Review Queue or SPAM Queue in Division B, the mapping can still be saved, but Strict Mapping must be disabled for that row.
| Setting | Example | Result |
|---|---|---|
| Original Queue | DivisionA / GenEmails_Billing | Source live queue for mailbox operations. |
| Review Queue | DivisionB / DAF_Central_REVIEW | Allowed only when Strict Mapping is disabled. |
| SPAM Queue | DivisionB / DAF_Central_SPAM | Allowed only when Strict Mapping is disabled. |
| SPAM Table | DivisionB / DAF_Central_SPAM | Allowed only when Strict Mapping is disabled and the table is otherwise healthy. |
This is useful when a tenant centralizes review or SPAM handling in a shared operational division. The tradeoff is that health depends more heavily on cross-division visibility and administrator discipline.