Who Is Allowed to Ask a New Question
There is a report builder here and there is no SQL. That is a real limitation for anybody who can write a query — and the reason it is not simply an oversight is that everything protecting your data sits in the layer a raw query would go underneath.
The most common request an analyst makes of a business system is the one it is least likely to grant: give me read access to the database and I will answer my own questions.
It is a completely reasonable request. It is also the request that removes every control the reporting layer exists to apply, and the honest conversation is about that rather than about capability.
What the builder is
A governed way to construct a report. You choose a dataset, pick fields from what that dataset offers, add filters and calculations, configure a chart, save the definition, and optionally put it through a certification review.
Around it sits a field-level model: a field can be marked not visible, and a definition that references it has that field dropped. So the set of things a report can contain is not the set of columns in the database — it is a curated surface, per organisation.
What SQL would be
Everything, without any of that. A raw query does not consult a dataset registry, does not know which fields an organisation marked hidden, and does not inherit whatever scoping the application applies to keep one organisation's data separate from another's.
That last point is the serious one in a system where many organisations share an installation. Application-level scoping is applied by the application. A query that goes underneath the application goes underneath the scoping.
A query workbench is not a reporting feature with extra power. It is a different trust boundary wearing a reporting feature's clothes.
The honest cost of not having it
Real, and worth stating without softening. An analyst who can write SQL is slowed to the speed of the builder, and the builder cannot express everything a query can — window functions, self-joins, complex sub-selects, set operations.
What that means in practice is that hard questions leave the system. The analyst exports, loads the export somewhere they control, and does the work there. Which is a workaround, and it has a consequence people underestimate: the answer now lives outside every control you have, including the field-level visibility that was carefully configured.
So the absence of SQL does not prevent data leaving. It changes the shape of how it leaves, from a query somebody could have audited to a spreadsheet nobody can see.
Where an analytical question gets answered
A standard report
Governed, certified, auditable
A custom report definition
Governed, field-level model applies
An export into a spreadsheet
Where hard questions actually go
A copy in somebody's analysis tool
Refreshed manually, forever, by one person
A read-only query workbench would sit around the middle: outside the field model, inside the audit trail. That is a defensible position and it is not the one this product has taken.
What to do if you have analysts
-
Push as much as possible into definitions
A saved definition is governed, certifiable and shared. A spreadsheet is none of those. Every question that can be expressed in the builder should be.
-
Treat the export as the boundary, and know where the copies are
The moment a question leaves, it leaves. Knowing which analyses live outside the system is worth more than trying to prevent them.
-
Use the API rather than a spreadsheet where you can
A read API call is authenticated, permissioned and repeatable. A manual export is none of those, and it is stale from the moment it is taken.
-
Ask for a dataset before asking for SQL
Most requests for database access are really requests for two tables that are not currently joinable. A dataset is a smaller ask and it keeps the controls.
Four questions about analytical access
Is there SQL access, and is it read-only?
A good answer sounds like
A direct answer.
What it actually means
Ours is a no. A yes needs the follow-up about scoping, because a raw query goes under the application.
What does the report builder refuse to express?
A good answer sounds like
A specific list.
What it actually means
A vendor who says "anything" has not been asked for a window function. The list is where your analysts will get stuck.
Does field-level visibility apply to the builder?
A good answer sounds like
Yes.
What it actually means
A builder outside the field model is SQL with a nicer interface and the same exposure.
Is there a read API?
A good answer sounds like
Yes, permissioned.
What it actually means
The realistic middle path. Better than an export and available today in a way SQL is not.
What AWRA OpsHub does today
- A custom report builder with a dataset registry, selectable fields, filters, calculations and chart configuration.
- A per-field visibility model, with hidden fields dropped from a definition rather than merely not offered.
- A certification workflow on a report definition, with the requester and reviewer recorded separately.
- Exports in several formats, and a read API for programmatic access.
- Report runs recorded, so who ran what and when is answerable.
What it does not do
- SQL access or a query workbench of any kind, read-only or otherwise.
- Arbitrary joins across datasets — a report is built on one.
- Window functions, self-joins, set operations or sub-selects in the builder.
- A semantic layer or metric store shared between the product and an external analysis tool.
- Any direct connection for an external business intelligence tool.
Not ours, by choice
- The absence of SQL is a real limitation and we would not pretend otherwise. The argument here is about where the trust boundary sits, not about whether analysts are inconvenienced — they are.
- A read-only workbench is a defensible product for a single-organisation deployment and a much harder one where many organisations share an installation. That distinction is the whole of the decision.
- Nothing here is Malaysian, Singaporean or Philippine. Southeast Asia is here because analyst bench strength is deep in those markets, so "give me database access" is an ordinary opening request rather than an unusual one.
What is not built for Singapore today can still be built for you
Anything described above as not built is a statement about what ships in the standard product today — not a limit on what AWRA OpsHub can do in Singapore. Kenya's eTIMS integration and its maintained payroll engine exist because Kenyan clients needed them and commissioned them; neither appeared by itself. The same door is open here. If an InvoiceNow access point, a CPF engine, a bank or mobile money feed, a statutory return format, a rule your own operation needs that the standard one does not have, or a link to a system you already run is what stands between you and a decision, tell us and we will scope it as a build — written spec, timeline and price — before you commit to anything.
InvoiceNow, Peppol and GST reporting
Sending and receiving structured invoices through a Peppol access point on the InvoiceNow network, invoice data transmitted to IRAS on the schedule your registration date puts you in, and GST returns assembled from the underlying documents rather than from a summary. Worth stating plainly: Peppol is a receiving network as much as a sending one, and the inbound half is the one most implementations leave until last.
PayNow, GIRO and multi-currency banking
PayNow collection matched to the invoice, GIRO files, and multi-currency bank feeds wired into the Payments Register — which is most of the point in a market where the bank account and the operation are usually in different countries.
The operational work, which is what most commissions actually are
An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.
Payroll and statutory returns
CPF contributions by age band and residency status, the Skills Development Levy, IR8A submission and IR21 tax clearance for departing foreign employees, computed on live records rather than assembled at year end.
Systems you already run
The accounting package, CRM, online store or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. No roadmap slide, and no pretending in a demo that something exists when it does not.
Tell us what you need integratedOur position
Express everything you can as saved definitions, use the read API rather than manual exports for anything recurring, and accept that genuinely hard analysis will happen outside the system. If a dataset you need does not exist, ask for the dataset — it is a far smaller request than database access and it is the one that keeps your field-level controls intact.
Ask what the builder cannot express
Not what it can. The list of refusals is short, specific, and it is exactly where your analysts will start exporting instead.
Talk about reporting and analyticsFrequently asked questions
Could I get a read-only replica?
That is a deployment conversation rather than a product feature, and the answer depends heavily on how you are hosted. It is a reasonable thing to ask about and it should be designed rather than improvised, because a replica inherits none of the application's scoping.
Is the read API a genuine substitute?
For recurring extraction, largely yes — it is authenticated, permissioned and repeatable, which a manual export is not. For exploratory analysis it is not, because exploration is precisely the activity that needs arbitrary queries.
Why is this rated low priority internally?
Because it is a large piece of work whose main beneficiaries are organisations with dedicated analysts, and most users of this product do not have one. That is a reason for the ordering rather than an argument that the gap is not real.
