Role-Based Access

Access by role, after sign-in, inside your company

Role-based access travel software should do one thing clearly: after a person signs in, they should see the work that belongs to them, and not the work that does not. A traveller needs trips, documents and requests. An approver needs the queue of decisions, with cost and policy in view. Finance needs spend, invoices and compliance. An admin needs the structure of the programme. Those are different jobs, and they should not share a single undifferentiated screen.

GTOS applies access by role inside each company's data boundary. Sign-in gets you into your company. Role decides what you can see and do there. GTOS is the Global Travel Operating System from Voraal, built on operating experience across 100,000+ trips.

Roles that match how a programme actually runs

The main company roles sit across the portals. Travellers work in My Mobility. Company admins, approvers, finance and leadership work in the Client Portal. Some people hold more than one role — a manager who also travels will both book and approve. The access model has to allow that without opening the entire programme.

Roles are defined next to employees and the organisation chart, because a role that is not attached to a real person and a real manager will not survive contact with approvals. When someone changes position, their access should change with the chart, rather than lingering on an old permission.

The desk works in Control Tower on the same trip record, with its own operating view. That is still bounded by per-client data separation.

Sign-in is necessary, and not sufficient

Two-step sign-in is available on the GTOS app, so access is not only a password. The app lives at app.mygtos.com, separate from this marketing site. After that sign-in, role-based access is what prevents a successful login from becoming open access to every trip, invoice or passport record in the company.

We do not claim a live, named single sign-on connector on this page. Conversations about identity providers are scoped during implementation and discussed in a demo. See SSO and Security. We do not claim certifications we do not hold.

Why this is a travel issue, not only an IT issue

If a traveller can see colleagues' itineraries they have no reason to see, or if finance cannot reach the invoices they are expected to close, the programme will be worked around. Role-based access is part of making GTOS usable at scale. The product is built to scale to 1,000+ employees per client, which is where informal sharing of logins becomes both a security problem and an operating problem. A clear role model is also what makes a demo account useful: each person in the walkthrough can see the workspace that matches their job, rather than a single screen that tries to be everything.

USD is the main currency on this site. Pricing is in USD and available on request.

Frequently asked questions

Can one person hold more than one role?

Yes. A manager who also travels is a common example: they book in My Mobility and approve requests they are responsible for. Access follows the roles they actually hold.

Is this the same as per-client data separation?

No. Separation is the boundary between companies. Role-based access is the boundary between people inside one company. Both apply.

Do you list supported identity providers here?

No. We do not publish a named connector list. Identity and single sign-on conversations are scoped during implementation.

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