Domains, access and roles

Typical entry points

A deployment can expose separate domains for public pages, the authenticated workspace, TALA Flow, UAT, and other product-specific experiences. In the current UAT pattern one application image can serve multiple domains while applying host-aware routing and permissions.

Access is server-enforced

Do not treat a hidden menu item as security. The platform uses role and permission checks on the server. Product navigation should reflect those permissions, but a guessed URL must still be rejected when the user lacks permission.

Geography and organisation scope

Campaign data can be scoped by geography. Workforce data can be scoped by organisation, department, role, or other configured boundaries. Before adding users, define the access model and verify it with test accounts at different levels.

Recommended setup order

1. Create or verify the organisation/tenant.
2. Configure shared geography and organisation structures.
3. Define roles and permissions.
4. Create administrators and test accounts.
5. Configure product-specific master data.
6. Test least-privilege access before bulk onboarding users.