How do ticketing permissions work across multiple venues and brands?
Ticketing permissions determine what a person or connected system can see and do. In a multi-venue operation, access usually needs more than a simple administrator/staff split. Common layers include functional roles (refund, create event, scan entry), resource scope (which venues or events), data scope (buyer fields versus aggregated reports), and approval controls for sensitive actions.
What are the main permission layers?
A regional manager might see performance across five venues while a local box-office employee can only serve customers at one venue. Finance may need settlement data without the ability to edit event capacity. An API token used for reporting should not inherit full event-editing permissions.
How should permissions be structured?
These are design examples, not universal roles. Some teams use separate accounts for elevated duties, time-limited access for contractors and explicit approval for bulk exports or refunds.
How are visibility and security different?
A visibility group limits which records appear in an interface, but robust security must also enforce authorization on server requests, exports, search results and APIs, as OWASP’s object-level authorization guidance explains. Hiding a button is not access control. Test whether a staff member can open another venue’s order by changing an identifier, whether exports respect the same scope, and whether revoked access takes effect promptly.
Nuweb publicly describes roles and permissions as controls over what users can do, and visibility groups as controls over which data they can see. Test the exact rights and inheritance in the account being evaluated.
What should administrators review regularly?
Review joiners, movers and leavers; dormant accounts; contractor access; privileged actions; API credentials; and exceptions created for major events. Keep auditable logs of who made sensitive changes, and test permission boundaries after introducing a new venue or brand.
Bottom line: permissions should follow the user’s actual job and resource scope, with sensitive operations restricted and tested independently of the interface.
How to test separation between organisations
Role-based permissions describe what someone can do; tenant, brand or visibility scope describes which records they can do it to. A finance user might need read-only access to Venue A’s settlements, while a group administrator can view several brands. Product tests should cover both dimensions: search, exports, bulk edits, API tokens and support impersonation. Removing a user from a venue should revoke access through all surfaces, not only the navigation menu. This is especially important where a shared infrastructure provider runs multiple independent ticketing businesses.