Not a tier they sit in. A role in AcuityQ™ is a named set of capabilities, each one small enough to say out loud — so "may approve a discount above 15%" can be granted to one person without handing them everything else a manager can do.
Screens in this module: Users & access · Roles & entitlement matrix · Reporting hierarchy · Admin & configuration · Integration hub · Security & DPDP · Product roadmap
Running a procurement review? Write to security@acuityq.ai and ask for the questionnaire pack rather than reading it off a page.
Schematic — one entry in the change trail
Illustrative. The shape is the point: every governed change records who, what, from, to, when — and which capability allowed it.
Roles & entitlement matrix
9 roles · 214 capabilitiesRoles and capabilities
Tiered permissions fail in the same way everywhere: somebody needs one thing a manager can do, so they are made a manager, and they quietly acquire thirty other things nobody intended to give them.
AcuityQ names the thirty things. Each is granted or not granted on its own, and a role is simply a named bundle you can hand to a new joiner in one movement. Capabilities can also be granted to a person directly, for a stated reason, and that grant is itself recorded.
Because the change trail records which capability permitted an action, an access review is a report rather than an archaeology exercise: who holds this capability, who used it, and on what.
Schematic — capabilities, named individually
The last one is deliberately a capability like any other, and it is the one worth reviewing every quarter.
Roles & entitlement matrix
Say it plainly: when an auditor sits down with a system, the first thing they ask to see is who can do what. In most products that is a query somebody writes, run against tables nobody wants to explain. Here it is a screen, and it is the same screen the people who set the permissions work in.
Every capability the role holds, on one screen, grouped by the part of the product it belongs to. Because a role is a set of named capabilities rather than a tier, there is nothing to infer from seniority — what the role reaches is written down, and what is not written down it does not reach.
A new role starts as a copy of the closest one that already exists. Building from an empty list produces a role that cannot do its job by Friday, and a role that cannot do its job gets widened in a hurry by somebody who has stopped reading. Cloning produces a role you can argue about line by line.
Put two roles next to each other and the difference between them is a list rather than a recollection. That list is the answer to “why can she do this and he cannot”, which is the question most access disputes actually turn on.
The question runs from the role as well as from the person: every holder, the scope each of them sits in, when they were granted it and by whom. A role nobody can enumerate the holders of is a role nobody is reviewing.
Who holds what, who granted it, when, who has never used it, and who can grant to others — assembled as a pack for a review rather than queried into existence the week the review is due. The reviewer signs off inside the product, and the sign-off is recorded.
The whole matrix, machine-readable, for the audit that will ask for it in a format its own tooling reads. It is generated from the same records the screen renders, so the file and the screen cannot disagree with each other.
A collaborator grant is a capability with an end date. Somebody covering a colleague for a fortnight is given the capability and the scope they need, with the date it expires set at the moment it is granted rather than promised for later. When the date passes the grant is removed without anybody remembering to remove it, and both the grant and its expiry sit in the trail.
Reporting hierarchy
Somebody’s reporting line, the org unit they sit in and the day they left are facts the HR system already holds. AcuityQ reads them. It does not ask an administrator to keep a second copy of the organisation in step with the first, because that copy is wrong within a quarter and nobody finds out until a report is wrong.
Branch, cluster, region and zone come across as structure rather than as a text field on a person. Somebody is placed in one unit, and their scope, their target, the dashboard they open and every roll-up above them is derived from that placement instead of being typed again in four places.
Joiner, mover and leaver arrive as events, not as a nightly file that overwrites everything. A joiner appears with the role their grade maps to and no scope until somebody grants it. A mover carries a dated change of scope, so the question “who could see this in March” has an answer in March’s terms rather than today’s.
When somebody is marked resigned, their book is not left sitting on a dead login while a ticket works its way through service management. It is raised automatically for a governed transfer — named receiver, named approver, recorded hand-over — which is the only way a book moves in this platform at all.
Schematic — synchronised from the HRMS, not typed twice
Illustrative. The ladder itself is configurable — four levels is a common shape, not a fixed one. What is not configurable is that it comes from one place.
Wide is not the same as up. Verticals are contained: a wide scope inside one line of business does not reach into another, so somebody who can see every branch in broking does not thereby acquire the insurance book. Rolling up above the verticals is a separate capability, held by very few people, and every grant of it appears in the access review by name rather than as a count.
What the platform enforces
A capability says what someone may do. Scoping says which records they may do it to. The change trail says what they actually did. The three are separate mechanisms, and none of them is a setting an administrator can quietly turn off.
Access is scoped by desk and by customer segment. A person on the Mumbai operations desk sees Mumbai operations cases; a rep who handles integrators does not browse the broking book because a report happened to include it.
Scope applies everywhere at once — screens, search, reports, exports and the API. There is no route into the data that quietly sits outside it.
Every governed object records who, what, from, to and when, for every field change. There is no configuration flag that disables it, no role that bypasses it, and no bulk operation that writes without it.
An administrator can read the trail. Nobody can edit it. That distinction is the whole value of having one.
An approval record names the person, the capability they used, the time, and the exact version of the object they approved — not the object as it stands today.
Change the quote after it is signed off and the approval does not follow it. The quote returns to the band it now falls into and is held until somebody signs again.
Segregation of duties is enforced, not advised. The person who requests a discount cannot be the person who approves it, even when one person holds both capabilities. Granting capabilities is separate from using them. Changing an SLA target is separate from reporting attainment against it. Where you want a stricter separation than the defaults, it is configured at deployment and the configuration is itself recorded.
Admin & configuration
Almost everything on this page that reads like a policy is a setting. The spine of it is the case taxonomy — four layers, because two is not enough to route on and five is more than anybody will maintain. Here is one case classified the whole way down.
| Layer | What it answers | Worked example | What it drives |
|---|---|---|---|
| Nature | What kind of thing is this at all? | Complaint | Which SLA policy applies, and whether the grievance ladder is in play from the first message rather than from the first reminder. |
| Function | Which business function owns the answer? | Settlements | The desk the case lands on, and therefore the working calendar its clocks are counted against. |
| Sub-function | Which process inside that function? | Fund pay-out | Routing within the desk, the knowledge articles offered to the agent, and the bucket the case is reported in. |
| Sub-sub-function | What precisely went wrong? | Credited to a closed bank account | The root-cause category, the resolution template, and whether anybody notices this is the third one this month. |
Read the third column downwards and it is one case. A complaint, owned by settlements, about a fund pay-out, credited to a closed bank account. That single string is what routes it, what decides the target it is measured against, what the root-cause report counts it in, and what tells somebody that four of these arrived this week from the same branch. The layers are yours to name; the shape is the product’s.
Fields you add yourself, with a type, a validation rule and a decision about whether they are required at creation or at closure. They appear in search, in reports and in the export, because a field that cannot be reported on is a field people stop filling in.
Three separate lists, deliberately. A tag is how people find things again. A disposition is how an interaction ended. A root cause is why it happened at all. Collapsing them into one list is how organisations end up with two hundred tags and no analysis.
The business-intelligence team uploads segment membership on their own schedule. Every row is validated before anything is applied and the upload reports back how many rows were accepted and how many rejected, with the reason against each rejected row rather than a count at the bottom.
Password rules, lockout behaviour, the second factor, idle and absolute session limits, and which actions force a fresh authentication. They are numbers you set, per deployment and where it matters per desk, rather than constants somebody chose for you.
Configuration is built and tried in a sandbox and then promoted, so the first place a new routing rule or a new SLA policy meets reality is not a Monday morning queue. What is promoted is the configuration. Production data does not travel the other way.
Every setting change records who, what, from, to and when, in the same trail as every other governed change. “When did this SLA target become four hours, and who decided that” is a question with a name and a timestamp attached to the answer.
A product where every policy change needs a release is a product you will stop changing. Not deliberately — it is simply that raising a change request to add a disposition is more effort than living without it. Eighteen months later the configuration describes the organisation you used to be, everybody has worked around it, and nobody says so out loud. That is the failure this screen exists to prevent, and it is why the list above is long rather than tidy.
Integration hub
An integration whose state nobody can see is an integration you hear about from a customer. The hub puts every connector, whether it is up, the volume of API calls it is carrying and a rolling error rate on one screen — so a connector that started failing quietly on Tuesday is visible on Tuesday.
Three numbers side by side, because each one alone misleads. A rolling rate, over a window, rather than a total since installation: a count that only goes up hides a problem that started this morning behind a year of successes.
Endpoints, payloads, error codes and what changes between versions, documented and versioned rather than described in a mail thread. Your integration team reads them before the project starts, not during it.
Payloads on the integration APIs are encrypted with AES-256, in addition to the transport security every connection already carries. The two are different protections against different problems, and one is not a substitute for the other.
| Kind of system | What crosses the boundary | Direction |
|---|---|---|
| Core / back-office | Customer master, holdings, balances and transactions | Read, at the moment of opening |
| Account opening | Application stage, current status and the reason for a rejection | Read |
| HRMS | People, reporting line, org units, joiner–mover–leaver events | Read, on a schedule |
| Telephony / CTI | Call events, agent state, and the reference to a recording held elsewhere | Both ways |
| Campaign platform | Audiences out, responses and withdrawals back | Both ways |
| Dialler | Call lists out, dispositions and attempt counts back | Both ways |
| Business intelligence / segmentation | Segment membership, as a scheduled upload with a row-level result | In |
| Analytics / warehouse | An event stream, for the reporting you do outside the product | Out |
| NPS / survey | Survey triggers out, scores and verbatim comments back onto the case | Both ways |
No vendor product is named on this page, and that is deliberate. Which specific systems have a certified connector today is a question for a call rather than a list on a marketing page: the list moves, and a stale one is worse than none. Tell us what you run and you will get a straight answer about what exists, what has been built once already, and what would be new work with a number attached to it.
Data protection
India's Digital Personal Data Protection Act turns several things that used to be policy statements into mechanisms somebody has to be able to operate on a Tuesday afternoon. These are the ones built into the product.
| Mechanism | How it works | Status |
|---|---|---|
| Consent with its wording | A consent is stored with the version of the words it was given against, and the time it was given. Wording is versioned and never edited in place — a new version is added, and existing consents stay attached to the words those people actually saw. | Present |
| Separate purposes | Agreement to be contacted about an enquiry and agreement to receive marketing are two records, stored and withdrawn separately. Withdrawing one does not withdraw the other, and neither is inferred from the other. | Present |
| Retention by deletion | A retention period is a job that deletes, not a paragraph in a notice. Enquiry records are held for 24 months from last contact and are then removed. The run is recorded, so you can show what was deleted and when. | Present |
| Export of a person's data | On a request, everything held about one person is assembled into a file — across cases, contacts, quotes and the trail — for the person handling the request to review and send. The request and its outcome are recorded. | Present |
| Erasure on exit | Erasure removes the personal data and keeps the transaction skeleton required for statutory records — a case still shows that it existed and when it closed, without naming the person. What survives erasure is set at deployment and written down. | Present |
| Governance over lead records | The same consent, retention and erasure mechanics extended to the lead management module — which is itself in build and not in production. Described on the lead management page. | Planned |
The wording in force on this site today: “I agree that Simcomm may use the details above to contact me about this enquiry.” Recorded against version 2026-09-v1. Requests about your own data go to privacy@acuityq.ai, and a complaint that is not answered well goes to the grievance officer.
Consent carrying its own wording and retention enforced by a deletion job are the two rows above that most policies stop at. These are the ones that are only ever code: nobody can write them into a notice, and nobody can operate them by hand on a Tuesday afternoon.
PAN, mobile number, e-mail address and bank details are encrypted at field level, not only on the volume underneath them. Volume encryption protects a stolen disc. Field encryption protects a query somebody ran who should not have.
Identifiers and contact numbers are masked on every screen, search result, report and export unless somebody unmasks one. Unmasking is break-glass: a capability, exercised one record at a time, and every use writes an entry to the audit log naming the person, the field and the record they opened.
Holdings, balances and transactions are fetched live at the moment a screen is opened and are not written down. There is no long-term copy of anybody’s portfolio in this platform — none to leak, none to export by accident, and none to forget to delete on exit.
An answer leaves for the mobile number or the e-mail address registered against the customer, not for whatever address the message happened to arrive from. Somebody who has taken over a mailbox does not thereby receive the answer to a question about an account that is not theirs.
Entries are written and never rewritten. There is no edit path from the application, no role that carries one, and no housekeeping job that quietly compacts old entries away. An audit log with an edit path is a log, not an audit.
The idle session timeout is configurable rather than fixed, and it is set per desk. A regulatory or dealing desk can be given a much shorter one than a back office without forcing the same number on everybody who happens to share the deployment.
| Figure | Why somebody asks for it | Value |
|---|---|---|
| Audit trail retention period | An audit log you cannot produce for the period actually under review is not evidence of anything. | audit trail retention period |
| Default idle session timeout | The number a security questionnaire asks for by name — and the first one a dealing desk asks to have lowered. | default idle session timeout, in minutes |
| Concurrency tested to | Not how many licences you may buy. How many people have actually been on it at once, in a test somebody ran and can describe. | concurrent users tested to |
| Recovery objectives (RTO / RPO) | These end up in a contract. A number invented for a web page is a number somebody will hold us to at three in the morning. | RTO and RPO committed in the contract |
Those four are blank on purpose. Each of them is a commitment rather than a description, and none will be printed here until somebody who can defend it in a meeting has supplied it. If you need them today, ask security@acuityq.ai and you will get them in writing, with a date on the answer.
Access itself
AcuityQ authenticates its own users where you have no directory to point it at: password rules you set rather than ones we hard-code, a second factor, handling for repeated failed attempts, and a forced re-authentication before a small number of sensitive actions.
Where single sign-on is deployed, AcuityQ sits behind it and your directory remains the place people are created and removed.
Idle and absolute session limits are settings, not constants, because a dealing desk and a back office do not want the same number. An administrator can list a user's active sessions and end them.
Sign-ins, sign-outs, failures and session revocations are recorded in the same trail as everything else, and they are reportable.
A person is deactivated, never deleted, because their name has to stay legible on ten thousand historical records. Deactivation ends their sessions and removes every capability at once.
When somebody moves desks, the change of scope is a recorded event with a date — so a question about who could see what in March has an answer.
Who holds which capability, who has not signed in for ninety days, who holds a capability they have never used, and who can grant capabilities to others — each is a report you can schedule, not an export somebody assembles by hand.
Reviews are the control auditors ask to see evidence of. Producing that evidence should take a morning, not a fortnight.
The honest boundary
AcuityQ authenticates its users and can sit behind your single sign-on where that is deployed, but it is not your directory. It does not provision people into other systems, it does not hold your organisation's identities, and it should not become the place your joiner process actually runs.
The product enforces the classification you give it. Deciding which fields are sensitive, which segments are restricted and how long a category should be kept is your work, and no software can do it on your behalf without guessing.
There is no risk register here, no control library mapped to a framework, no policy lifecycle and no place to run an enterprise audit programme. AcuityQ produces evidence about itself — who holds what, who did what, what changed — and that evidence is meant to be read by the governance tool you already run, not to replace it.
The reporting line and the org units are read from the HR system. Where there is no HR system to read, somebody has to decide the structure and maintain it, and that decision is not one the platform can make for you. A hierarchy typed into a product because it was never agreed anywhere else is a hierarchy that will be wrong by the next quarter.
Masking, break-glass unmasking and the trail govern what the product shows and record who looked. None of that stops somebody photographing a screen, reading a number down a phone or re-typing it into a spreadsheet. Those are problems for your endpoint and DLP controls, and we would rather say so than let a masking feature stand in for them.
Everything here is a mechanism. Compliance is the mechanism plus somebody operating it, plus the record that they did. AcuityQ makes the second and third parts possible; it cannot supply the first on your behalf.
This page claims none, and you should be suspicious of any page that claims one without naming the scope, the certifying body and the date. If a certification matters to your procurement, ask us directly and you will get a written answer about what is and is not held, and what is in progress — from a person, with a date on it.
Write to security@acuityq.ai.
With the word Planned, in the same place the control is described — on this site, in the questionnaire pack, and in a proposal. A control that is planned is never written in the present tense, and it is never described in a way that lets a reader assume it is running. The one planned item on this page is tagged in the table above.
The same applies at module level: lead management is in build, and it says so on its own page before it says anything else.
In a normal deployment you are, for the personal data you put into AcuityQ, and Simcomm processes it on your instructions. That allocation belongs in the deployment contract, in words both sides have read, rather than in a paragraph on a marketing page — so we will not state yours here.
For personal data you give us — an enquiry from this website, for instance — Simcomm is the fiduciary, and the privacy notice says what we do with it.
Only by granting themselves the scope first — which is a capability, which is recorded, and which shows up in the access review as a grant somebody made to themselves. There is no hidden super-user that reads records without leaving a trail, because a trail with a documented exception in it is not a trail.
Product roadmap
There is a roadmap screen in the product and a roadmap document for customers. Neither is published on this website. It is shown under NDA, in a meeting, with somebody in the room who can answer the question you will ask about the third item.
| State | What it means | What you may assume from it |
|---|---|---|
| Scoped | Written down as a requirement, sized, and not started. | Nothing yet. It is an intention with a shape and an owner. |
| In build | Being written now, against a named phase. | That somebody can walk you through what exists — not that a date is safe. |
| Pilot | Running in one estate, behind a flag, under observation. | That it works for one deployment being watched. Not that it is general. |
| Done | In the product, on the module map, demonstrable. | That you can open it and we will show it to you on request. |
Where an open item gates a phase — a decision nobody has taken yet, a dependency on a system we do not control, a question still sitting with your compliance team — it is named on the same page as the phase it blocks. Not in an appendix, and not in week six of the deployment. A gate you knew about in the first meeting is a plan. The same gate discovered later is an argument about who should have said something.
Nothing on this website is described as shipped because it is on a roadmap. The module map marks what is live and what is in build, and a module that is in build says so before it says anything else. If you find a sentence here that reads as though something exists when it does not, that is a defect in the page and we would like to be told about it.
If you have a security or data-protection questionnaire to fill in, send it. We would rather answer your questions in your format than ask you to read ours.