Security

How your billing workspace is protected

What your clients owe you is commercially sensitive. This page describes the controls that are actually in place — mechanisms, not adjectives — and is equally clear about what Umikflow does not do.

Controls in place

Where access is decided

The central design choice is that authorization lives in the database. The interface decides what to draw; Postgres decides what may be read.

Authentication

Accounts are created and verified through Supabase Auth with an email address and a password. Email confirmation is part of sign-up, and a session is required before any workspace data is requested.

Database-level access control

Client and payment tables have Row Level Security enabled, with policies that scope every read and write to the account that owns the row. The check runs inside Postgres on each query, not in the interface.

Workspace isolation

One merchant cannot read, edit or delete another merchant's clients or payments. Because the constraint is a database policy rather than a UI condition, it holds regardless of how the request was made.

Role separation

Accounts are either merchants or administrators, and the role is stored on the profile. An administrator area exists for moderation; a merchant account cannot reach it.

Administrator boundaries

Administrators can view the account list, platform-level counts and the moderation log, and can suspend or reactivate a merchant account. They do not have a route into any merchant's client records or payment ledger.

Privilege boundaries in the browser

The application is configured with the public anon key only. The service-role key, which bypasses Row Level Security, is never sent to the browser and is not present in the client bundle.

Audited moderation

Suspending or reactivating an account writes an entry to an activity log in the same database transaction as the change itself, so a status change cannot occur without a corresponding record. The log stores status transitions and changed field names — never credentials, tokens, or client and payment data.

Reversible deletion

Removing a client or a payment marks the row as deleted rather than destroying it, and the application issues no hard delete against either table. That is what makes an accidental removal recoverable.

In practice

Why database-level rules matter

A great deal of software enforces access in the screens: the page asks for the rows belonging to the signed-in user, and the rows it gets back are the rows it asked for. That works until a query is written slightly differently, or a request arrives from somewhere other than the interface.

Umikflow puts the rule underneath that. Row Level Security policies on the client and payment tables restrict what any query may return, based on the authenticated identity making it. A request that forgot to filter by owner does not return more rows; it returns none.

The same principle governs account state. Role and status are not columns the browser is permitted to write — the grants allow an authenticated user to update their own name, address and contact details, and nothing else. Changing a role or suspending an account goes through a dedicated database function that verifies the caller, refuses self-moderation, and records what it did.

A suspended account can still sign in and sees an explanatory screen, but reaches no client or payment rows at all, because the same database check refuses them.

Your account

Practical things you control

Password resets

Handled through Supabase Auth. You request a link, it arrives at your registered address, and it works once. Umikflow never sees or stores your password.

Email confirmation

Sign-up sends a confirmation link to the address you gave, so an account cannot be created against an address you do not control.

What you enter

Your client and payment records are data you chose to enter. Only store what you actually need in order to bill and follow up.

Plain statements

What Umikflow does not claim

Security pages are usually a list of adjectives. Here is the opposite — the things that are not true of Umikflow, stated so you do not have to guess.

We do not hold SOC 2, ISO 27001, PCI DSS or any other security certification, and we do not claim to.
We are not a payment processor. No card details, bank credentials or payment instruments are collected, stored or transmitted by Umikflow.
We do not claim "military-grade", "enterprise-grade", "bank-level" or "zero-risk" security. Those phrases describe nothing specific.
No software is completely secure, and we will not tell you otherwise.

Reporting a security issue

If you believe you have found a vulnerability, write to support@umikflow.com with enough detail to reproduce it. Please give us a reasonable opportunity to respond before disclosing it publicly.

Ready to take control of your client billing?

Create invoices, record payments, and follow up on outstanding balances — then send a WhatsApp reminder when you need to.

Get Started Free Sign In