Design role-based access so the programme stays inside its boundaries
Role-based access travel software should make a dull promise and keep it: after a person signs in, they see the work that belongs to them, and not the work that does not. When that promise fails, two things happen at once. People who need a queue cannot find it, and people who should not see a leadership itinerary, another client's file, or another department's spend, can. This guide is about designing that model before you go live, and keeping it current when people change jobs.
The guide is written by the team behind GTOS, the Global Travel Operating System from Voraal, and is built on operating experience across 100,000+ trips. The matching product page is role-based access. The glossary entry is role-based access. Related pages cover employees and organisation roles, data separation and HR data.
1. Map roles to real jobs, not to a generic user
A traveller needs trips, documents and requests, in My Mobility, including as a mobile web experience on a phone. An approver needs the decision queue, with cost and policy in view. Finance needs spend, invoices and compliance. An admin needs the structure of the programme. The desk needs Control Tower. Some people hold more than one of those jobs — a manager who also travels will both book and approve. The model has to allow that without opening the entire programme.
2. Attach roles to the organisation chart
A role that is not attached to a real person and a real manager will not survive contact with approvals. When someone changes department, is promoted, or leaves, their access should change with the chart. Leavers who remain approvers are a common failure. Joiners who cannot book are another. Keeping the chart current is therefore an access task as well as an HR task.
3. Separate company boundaries from roles
Role decides what you can do inside your company. Data separation decides that you are inside your company at all. An agency servicing more than one client, or a group with more than one entity, needs both. A correctly assigned role in the wrong company file is still a breach of the boundary.
4. Treat sign-in as part of access
Two-step sign-in is available on the GTOS app. Access design should assume that credentials matter, and that a forwarded screenshot is not a role. See Security. We do not invent certification marks on this page.
USD is the main currency on this site. Pricing is in USD and available on request. Each company sees only its own data. A demo should sign in as a traveller, an approver, a finance user and an admin — and, if you run more than one entity or client, should show what is not visible as well as what is. Bring your actual job titles. The walkthrough is more useful when it uses your chart rather than a generic set of names.
Frequently asked questions
Can one person be both a traveller and an approver?
Yes. The access model is designed to allow more than one role without opening the entire programme.
What happens when someone leaves or changes job?
Access should follow the organisation chart. A leaver should not remain in an approval chain, and a new role should carry the access that role requires.
Is role-based access the same as per-client data separation?
No. Roles decide what a person can do inside a company file. Data separation keeps that file inside its own boundary.
Related
See GTOS in a demo
We are now taking early-access requests. Demo accounts are available now.
- A walkthrough of the Client Portal, My Mobility and Control Tower
- Your travel policy, set up in a demo account
- USD pricing discussed on request, with PKR quotes available
Prefer email or WhatsApp? insights@goglobal.pk · +92 320 4111222