After a recent org restructure, we moved several queues from Division A to Division B. Now users in Division B can see the queues but can’t modify the routing rules.
The queues appear in the admin panel, but the ‘Edit’ button is grayed out. The users have the routing:queue:edit permission in Division B. Why can’t they edit?
Moving a queue to a new division doesn’t automatically update the access control on child objects.
The queue’s routing rules, wrap-up codes, and skill assignments may still be bound to Division A. You need to explicitly move each child object to Division B. Use the API to bulk-update divisions:
for obj_id in child_object_ids:
api.post_authorization_division_object(div_b_id, 'QUEUE', obj_id)
We discovered this the hard way during our compliance restructure.
200 queues were moved to a new compliance division. The queues were visible, but 15 Data Tables, 8 Architect flows, and 30 wrap-up codes remained in the old division. It took 3 days to identify and move every dependent object.
From a SOC2 audit perspective, orphaned objects in the wrong division are an access control finding.
If an Architect flow in Division A references a Data Table that should be in Division B, users in Division A can indirectly access Division B’s data through the flow. This violates the principle of least privilege.
# Audit all objects to verify division assignment
object_types = ['QUEUE', 'FLOW', 'DATATABLE', 'WRAPUPCODE']
for obj_type in object_types:
objects = api.get_authorization_division_grants(div_id, obj_type)
for obj in objects:
if obj.division.id != expected_div_id:
print(f'ORPHAN: {obj_type} {obj.name} in wrong division {obj.division.name}')
Run this after every org restructure.