The admin portal is ours, and this page explains what we can see.
The back office is not a portal an agency is given. It is where the company running Insoora keeps the platform working — accepting borderline documents, writing insurer rules, answering enquiries, and keeping an audit trail of who did what. If you are about to put your book of business on this platform, what you want from this page is an honest account of that access.
- Five staff roles, not one god account
- Every privileged action written to an audit log
- Configuration screens are not shown here, on purpose
- The one screen below uses invented agency names
On this page
The correction most readers need
You do not get an admin portal. We have one.
Worth settling in the first paragraph, because the assumption runs the other way.
Insoora has three portals. An agent signs into the agent portal, a policyholder into the customer portal, and the company that operates the platform signs into the back office. An agency owner's own administrative screens — the team, the plan, the credits — are inside the agent portal, not here.
The back office is different in kind from the other two, and the difference is the thing to understand: its queries are not tenant-scoped. An agent portal session can only ever reach one agency's data by construction. A back-office session is a session that can look across every agency's data, because the work it exists to do — accepting a borderline document, writing a rule for a stubborn insurer layout, investigating why an upload failed — cannot be done from inside one tenant.
That is a genuine trust relationship and it should be treated as one. The rest of this page is about the controls on it rather than about features.
- Three portals: agent, customer, back office
- Your agency's own administration lives in the agent portal
- Back-office queries are not tenant-scoped — that is what the role is for
What it does not do
There is no white-label or reseller arrangement in which an agency gets its own back office across other agencies' data. The back office is one, and it belongs to the operator of the platform.
Not one god account
The five staff roles, and what separates them
The useful fact here is that the roles are different from each other. A support account cannot change anything, and only one role reaches payment credentials.
Super admin
Everything, including payment gateway credentials and changing another account's role. The smallest role by headcount and the one with the fewest holders.
Admin
Operational administration across agencies, plans and extraction configuration — but not gateway credentials and not role changes.
Support
Read-only. Can see users, usage and billing in order to answer a question, cannot change anything, and never sees payment credentials.
Reviewer
Works on documents: reading, processing, reviewing and confirming extractions, plus export. No user administration and no billing.
Viewer
Document read access and nothing else. The role for somebody who needs to look at a case without being able to act on it.
One screen, and why only one
The business overview, with invented agencies
This is the screen an operator starts the day on: counts, and a queue of agencies that need something done. The configuration screens are discussed below and deliberately not drawn.
Business overview
How many agencies, how many policies processed, how many extractions awaiting review, how many website enquiries unanswered — and the queue of what needs an operator today.
An insurer rule, mid-test
The one configuration screen shown, because it is the one that explains how a stubborn insurer layout gets read: a human writes a rule and tests it against a document before saving.
The absences are the point
What this page does not show you, and why
A marketing page that walks you through a payment gateway configuration screen has told you something about the company publishing it.
The back office has screens for payment gateway settings, document storage, the AI and OCR providers, platform settings and the audit log. They are named here so that this page is not pretending they do not exist. None of them is drawn, and none of them will be.
The reason is not that they are embarrassing. It is that a screenshot of a configuration surface tells a reader which fields exist, how they are grouped and what a valid value looks like — and for a security or payment surface that is reconnaissance rather than marketing. The brief for this website rules it out and it would be the right call anyway.
What a reader is entitled to is the shape of the thing: there is a back office, five roles with genuinely different reach, privileged actions are recorded, and configuration is done by a person who has to test a rule before saving it. That is on this page. The field layouts are not.
On the audit log
Privileged actions are written to an audit log, and reading that log is itself a separate permission rather than something every staff role has.
What this page will not do is publish what the log records field by field, or show it. A log is worth having because it is complete and because tampering with it would show; neither property is improved by describing its schema on a public page.
On the limits of this reassurance
An audit log is a record, not a prevention. It tells you after the fact that a privileged action happened; it does not stop one. Role separation is the control that narrows who could take the action in the first place, and the honest position is that both are in place and neither is a guarantee.
Insoora holds no security certification and has not been penetration tested. Those two sentences belong on this page more than on any other.
Concretely
What an operator can reach in your agency's data
The question behind every visit to a page like this. Answered row by row.
| Your data | Can the back office reach it? | Which role |
|---|---|---|
| Your policy records and extracted fields | Yes. Reviewing a failed or borderline extraction is the core back-office job. | Reviewer, Admin, Super admin; Viewer and Support can read |
| Your uploaded policy documents | Yes, through the same scoped download route everything else uses. There is no bypass that serves bytes without re-deriving the caller. | Roles with document read access |
| Your customers' contact details | Yes, where the role includes revealing them. Masking is the default, and unmasking is a separate permission rather than a property of being staff. | Roles granted it explicitly |
| Your plan, credits, subscriptions and payments | Yes, as records — to answer a billing question or correct a credit balance. | Admin and Super admin; Support read-only |
| Payment gateway credentials | One role only, and never Support. | Super admin |
| Changing another account's role | One role only. | Super admin |
| Your password | No. Passwords are stored hashed and cannot be read back by anybody, including us. | Nobody |
If what you need is a contractual commitment about operator access rather than a description of it, the Privacy Policy is the document to read and the office is the place to ask. A table on a marketing page is not a data processing agreement.
Stated plainly
What this page is not claiming
The four things a reader could reasonably over-read from everything above.
Role separation is not isolation
Five roles with different reach is better than one account with everything. It is not a guarantee that no operator can see your records — the back office exists precisely because somebody has to be able to.
No certification, no penetration test
Insoora holds no security certification of any kind, has not been penetration tested, and does not claim IRDAI approval or any government certification. There is also no multi-factor authentication on accounts yet.
No published retention schedule
Nothing is deleted automatically, because the platform is built to keep policy records findable for years. A deletion request is handled by hand, and some records may still be retained where law, tax, an unresolved dispute or a backup's expiry cycle requires it.
The screen above is invented
The agency names, counts and queue entries are fictional and the screen is drawn in markup rather than captured. No real agency's position appears on this website.
Frequently asked questions
Questions this page should answer
Keep reading
Where to go next
The pages that cover the next part of this, with what each one adds.
If operator access is your question, ask it directly.
A page can describe the controls. Only a conversation can answer what your business needs committed in writing.