Enterprise login, roles and audit trail.

The permission matrix on this page is the readable form of the underlying idea: rather than a handful of fixed account types, access is defined as a grid of individual permissions against individual roles, so you decide — per role — exactly which capabilities are switched on. That is what makes least-privilege practical rather than aspirational: a cashier role can be granted the ability to take a sale and open a till but nothing that touches pricing, refunds above a threshold, cost data or another outlet; a shift manager role can be given the approvals and reporting it needs and no more; and where the built-in roles do not fit your business you can define custom roles that carry precisely the permissions you choose. The page also describes hierarchical inheritance, which means roles can build on one another — a senior role inheriting a junior role's grants and adding to them — so you are not re-checking the same fifty boxes for every variant. The practical effect is that managers and cashiers see only what you have granted them, and "what can this person do" becomes a matter of reading one row of a matrix rather than reconstructing it from scattered settings. Two honest caveats worth stating. First, least-privilege is a design you author; the tool gives you the granularity, but the discipline of granting narrowly and reviewing periodically is yours. Second, get the specific list of grantable permissions and how inheritance resolves conflicts confirmed with sales against your own org structure, because the exact catalogue is what determines whether the matrix can express the separation of duties you have in mind.

No — and this is the answer we want to be completely straight about, because the compliance words on this page are easy to misread. SOC 2, PCI-DSS and GDPR are not properties that a piece of software can hand you. They are programmes your organisation achieves and, in the case of SOC 2 and PCI-DSS, has attested or certified by your own auditors or assessor, against your own processes, people and environment. What Vertex provides is tooling that supports that work: detailed, time-stamped, access-controlled records of who did what and when, the access controls and role separation described elsewhere on this page, and reports you can put in front of an assessor. Those are genuinely useful inputs to a compliance programme — but the programme, the scoping, the evidence-gathering and the certification are yours to run. On the word "immutable": we would rather describe these as records that are time-stamped and access-controlled, retained under the controls you configure, than lean on an absolute claim about being unalterable, because the honest framing is more defensible and more useful to you when an auditor asks how the log is protected. And the figures on the dashboard — the 12,482 events, the 849k, the 142 — are illustrative sample data drawn to make a mock screen look populated. They are not measurements from a real deployment, not a projection of your volumes, and not a benchmark to plan against. Take your specific compliance obligations to your own auditor, assessor or counsel; the product-side question for sales is what evidence, exports and retention controls the audit trail gives you to support that effort.

Yes, in the sense that the controls are there for you to configure — and it is worth being precise about that word "configure," because these are tools you set up and operate rather than a guarantee that switches itself on. Multi-factor authentication can be required, and the sensible pattern the page points at is to make it mandatory for the high-privilege roles first — anyone who can change prices, issue refunds, export data, manage users or reach across outlets — and to extend it from there. On the session side, the tooling lets you see active sessions, terminate a session remotely when a device is lost or a member of staff leaves mid-shift, and review login patterns across your locations so an unusual sign-in stands out. All of that works across outlets from a central place, which is the point of running one directory rather than a login per site. The honest boundary is this: authentication controls protect the account, but they do not by themselves secure the device the account is used on. A shared terminal left unlocked on a counter, a manager's laptop without a screen lock, an unpatched card reader — those are endpoint and physical-security responsibilities that stay partly yours, and MFA does not substitute for them. So enforce MFA on the privileged roles, use the session controls as part of a joiner-mover-leaver routine, and pair them with the device and premises discipline that only you can put in place. Confirm the specific MFA methods supported and how session policy is scoped per role and per outlet with sales against your own setup.

That is the intent of the HRM integration this page describes: rather than provisioning and de-provisioning staff by hand in two systems, the aim is to connect your HR system so that a joiner recorded there can flow through to an account with the right role, and — the half that matters far more for security — a leaver recorded there triggers the account being disabled promptly. Slow offboarding is one of the most common and most expensive access-control failures a business has, so an integration that helps a departure in the HR system reach the point of sale quickly is worth having. Where we want to be careful is coverage. The page supports connecting major HRIS platforms and custom tools, but we are not going to name a specific vendor and present it as a guaranteed, tested, turnkey connector, because HR systems differ in what they expose, how they represent employment status, and whether they push changes or expect to be polled — and "has an API" is not the same as "maps cleanly to your roles and outlets." So the right move is to route the specific question to sales in writing: name the HRIS you run and the version, ask for the list of supported integrations and what each one actually syncs, and ask what the path is for a system that is not on that list — a custom integration, a directory sync, or a manual process backed by the audit trail. And whatever the integration does, keep a human check on offboarding, because the moment you most need a leaver's access gone is the moment you least want to discover a sync was silently failing.

Realistically, no — capabilities like enterprise single sign-on, a central provisioned directory, granular role-based permissions and full audit trails are typically part of an enterprise or priority tier rather than something bundled into every plan, and we would rather tell you that plainly than let you assume it and be surprised at quoting. The reason is not arbitrary: SSO and directory integration involve setup and support work specific to your identity provider, and the organisations that need cross-outlet role separation and compliance-grade audit trails are generally the ones on the larger plans in the first place. Because tiers, packaging and what is included at each level change over time and can vary by region and by how many outlets you run, the accurate thing to do is confirm the current availability and any add-on details with our sales and pricing team rather than relying on a marketing page to be the source of truth on what your plan includes. When you ask, it is worth asking two things together: which tier unlocks SSO and RBAC, and whether the identity-provider and HRIS integrations you need in particular are covered at that tier or scoped as implementation work on top — because those two answers together are what actually determine the cost and the timeline of getting this live for your business.