Fluids capability

Platform & Security

The part your IT person will ask about, and the reason the rest of it can be trusted. Isolation, permissions and correctness are structural properties here — enforced by the build and the database, not by developer discipline.

Four guarantees

Enforced, not intended

One branch cannot see another's data

Every table in the database says which branch or company it belongs to, and the build fails if a new one is added without saying. So it is not something a developer has to remember on each screen — a query cannot silently forget which branch it is in.

It will not start if a screen is left unprotected

On startup the server checks every screen that changes data for both a role check and a module check, and refuses to run if one is missing. The number of exceptions is currently zero, and it is only allowed to go down.

The GST is worked out twice, by two different pieces of code

Once in the application and once in the database, tested against a shared set of known-correct answers. If the two ever disagree on an invoice, the database refuses to issue it rather than letting a wrong figure onto a tax document.

A double-tap cannot create a duplicate

Every save carries a key that identifies it. A patchy connection, an impatient second tap or two tabs open on the same form replay the original answer instead of creating a second purchase order.

Tenancy

Multi-company and multi-branch, done properly

Every table declares its scope

All 239 tables in the database are registered against an explicit scoping axis — branch, company, location, inherited from a parent, or genuinely global. A global table has to state a reason. Continuous integration fails if a table exists without an entry.

The query cannot forget

Database access is constructed from that registry per request, so a query is scoped by construction rather than by a developer remembering to add a filter. Architecture tests fail the build if an unscoped tenant query appears.

Cross-branch is a workflow, not a leak

Moving stock between branches goes through requested, approved, dispatched and received states, visible to both ends. There is no other path by which one branch sees another branch's data.

Row-level security as a backstop

Database policies sit underneath the application as a second line of defence, so a mistake at the application layer does not become a data exposure.

Access control

Who can do what, and how it is proven

13 roles, at three levels of reach: A global support role, a company-level super administrator that spans every branch, and eleven branch-scoped roles: administrator, branch manager, accountant, sales, purchase, production, inventory, quality control, inspection, service and viewer. The list in the code and the list in the database are checked against each other automatically, so they cannot drift.
Four independent authorisation axes: Role, module and sub-module permission, business mode and plant capability are all evaluated and combined. All of them fail closed — an unrecognised permission is denied, not allowed.
64 enforced permission keys: Generated from a single source and shipped to the browser as well as enforced on the server, so the interface and the API cannot disagree about what a user may do.
A disabled feature says so: Turning a module off returns an explicit feature-disabled response rather than a 404 or a generic error, so a user is told they do not have it instead of being told something is broken.
Session policy: Cookie-based sessions with a single active session per user, a password-verified way to log out your other device, sixty-minute idle logout, and every authentication failure recorded.

Configuration

Change the product without changing the code

🎛️

Module Control Panel

28 top-level modules and 45 sub-modules switched on or off at global, customer or branch scope, with the more specific scope winning and inherited-versus-overridden shown clearly. Turning a parent off cascades to its children. Core modules are always on, so an administrator cannot lock everybody out.

🏭

Plant profiles

Four presets — full plant, on-site production, import and fill, bulk fill — expanding into capability flags for gas sourcing, bulk storage, mandatory quality control and servicing. The company sets the ceiling; a branch may narrow it but never widen it.

⚗️

Business mode

Gas only, item only, or both — enforced on writes at the line level, not merely hidden in the navigation. A disabled line type cannot be created even by an API call.

🖨️

Print Center

17 document types with per-branch, per-document template configuration, section toggles, administrator-authored header and footer, a live preview and server-rendered PDF. Eight starter templates ship configured.

✉️

Email Center

Sender identity and recipient routing configured per branch and per department across eleven departments, each with its own mail server settings and an enable toggle. Credentials are referenced by name and never stored in the configuration.

🎨

Nine interface themes

Five dark and four light, chosen live and remembered per user. A small thing — but a shift working under plant lighting at 2am notices.

Hand-offs

The SLA engine

The most common failure in a plant is not a wrong decision — it is a correct decision that nobody was told about. This is the part of Fluids that fixes that.

30 tracked stages: Events across the system — enquiry created, production queued, inspection placed on hold, refill inwarded, sales return available and twenty-five more — are emitted as tracking events rather than left implicit.
Rules are data: For each stage you configure which role is notified, who else is copied, the SLA in hours, how long before escalation, which role it escalates to, the priority, and whether the rule is branch-specific. All from an admin screen, with no deployment.
Escalation actually fires: A scheduled job promotes overdue items to the escalation role. If the nominated role has nobody staffed, it falls back to the branch manager rather than notifying no one.
An inbox people will use: Unread and escalated tabs, per-user read state, priority and due dates, pagination for older items, refresh on tab focus, mark-all-read, and a branch switcher for users who cover more than one site.

Scheduled work

Eight jobs that run whether anyone remembers or not

Purchase automation: Drafts purchase orders from the price book and raises RFQs by category policy — never auto-spends.
Sales automation: Reads enquiries from a mailbox, pulls out the customer and the items, and sends anything it is unsure about to a person.
Reservation reclaim: Frees up stock that was held for an order which never happened.
Accounting outbox: Hands documents to your accounts package daily, keeps retrying if it fails, and writes the voucher number back.
Dunning run: Groups overdue invoices by customer and sends payment reminders, logging every attempt.
Invoice consolidation: Rolls a month of delivery challans into a single consolidated customer invoice.
Rental billing: Bills accrued rent and demurrage monthly against the billing watermark.
Item cost reconciliation: Rebuilds your average item cost from the stock ledger.

What gets audited

Every mutating request logged with the user and the branch
Every unauthorised and forbidden response recorded, not just the successful ones
Session heartbeat and duration tracked for security review
Database-level change triggers with a viewer interface over the change log
Quality result edits written to a separate record that nobody can go back and change
Every e-way bill and IRN call recorded as an event with its response
Module configuration changes audited with who changed what and when
Every dunning attempt logged whether or not it was delivered

Runtime

How it is hosted and kept standing

Hosting: Managed cloud infrastructure in the Mumbai region, with a managed PostgreSQL database. Nothing to run or patch in your plant.
Hardening: Security headers with content security policy and strict transport security, a fail-closed cross-origin allowlist that refuses cross-origin requests in production if it is empty, and three-tier rate limiting across authentication, write and read traffic.
Observability: Error tracking and structured logging on the server, plus error and performance monitoring in the browser, so a problem is usually seen before it is reported.
Reliability of writes: Every write carries a key that identifies it: a retry replays the original response, and a duplicate arriving while the first is still running is rejected rather than duplicated.
Documentation: 80 written operating guides across 10 categories ship with the product, generated from the specifications and checked for freshness in continuous integration.

Get Started

Send us your IT questionnaire

We would rather answer the security and architecture questions early than discover them at contract stage. Ask us anything on this page in detail.

Talk to us ← Back to Fluids

Enforced, not intended

One branch cannot see another's data

It will not start if a screen is left unprotected

The GST is worked out twice, by two different pieces of code

A double-tap cannot create a duplicate

Every save carries a key that identifies it. A patchy connection, an impatient second tap or two tabs open on the same form replay the original answer instead of creating a second purchase order.

What gets audited

Every mutating request logged with the user and the branch

Every unauthorised and forbidden response recorded, not just the successful ones

Session heartbeat and duration tracked for security review

Database-level change triggers with a viewer interface over the change log

Quality result edits written to a separate record that nobody can go back and change

Every e-way bill and IRN call recorded as an event with its response

Module configuration changes audited with who changed what and when

Every dunning attempt logged whether or not it was delivered