Isolation is enforced by the database
Most systems check permissions in application code. Alano checks them inside PostgreSQL, on every query — so a bug in the interface, a direct API call, or a stray script all meet the same wall.
How workspaces are separated
Every record Alano stores carries the id of the organization it belongs to. That column is the tenant boundary, and it is checked by the database rather than by the application.
- Row-Level Security is enabled on 105 of the 106 tables in the application schema, enforced by 310 individual policies.
- Each policy resolves membership through a single pair of functions — one for "is a member of this organization", one for "is an admin of it" — so the rule is defined once and reused, not re-implemented per table.
- Reads and writes are member-level; deletes are admin-only.
- The same policies govern the REST API. Asking for a record id belonging to another workspace returns nothing, because the row is filtered out before the query result is assembled.
The practical consequence: bypassing the interface gains an attacker nothing. There is no query that returns another workspace's rows, because PostgreSQL will not produce one.
Groups and hierarchy
Within a workspace, visibility is organised by group. Groups can be nested, and a parent group sees the data of its children — a sales VP over a regional team, for instance, without anyone assigning records one by one.
Ancestor relationships are resolved from a cached hierarchy so the check stays fast as the tree grows.
Access to an individual record
When Alano decides whether you can open a specific customer, contact, deal or task, it applies three rules in a fixed order:
- The person who created the record keeps access to it.
- An explicit restricted-viewer list is checked next, and overrides group membership.
- Otherwise the group hierarchy decides.
Visibility set on an epic or a sprint cascades to the deals and tasks linked to it, and a record linked to both inherits the combined restrictions — so access is configured at the level people actually think about, not record by record.
Field-level permissions
View and edit rights are set per field, per group, on Customers, Contacts, Deals and Tasks. The two are independent: a group can be allowed to read a field it cannot change.
Enforcement is server-side. A field a group may not see is stripped from the result before it leaves the database, so it is absent from the API response rather than hidden by the interface. Each field also declares how it behaves when a record is locked, so a won deal can freeze its commercial fields while notes stay open.
Read-only members
A member can be marked read-only. This is enforced with restrictive database policies, which combine with the ordinary rules rather than replacing them — so a read-only member cannot be granted write access by any other policy on the table.
The audit trail
Around twenty database triggers write to the audit log. Because they sit on the tables themselves, an action cannot be performed without being recorded — there is no application path that skips it.
- Each entry holds the entity, the action, the actor, the timestamp, and the values before and after the change.
- Creates, updates, comments, group changes and membership changes are all covered.
- Only insert and select are permitted, so entries are append-only from the application — they cannot be edited or deleted through the product.
- Reads are permission-filtered: you see audit entries for records you can already access, and no others.
Limits and abuse controls
The public inbound API — the one that takes leads from your website — is rate limited per organization, with configurable ceilings per minute, hour and day, a burst allowance, and a block window when a caller exceeds them.
- Violations are recorded, and repeat offenders are tracked by IP reputation.
- Each API key is scoped to the domains it may be called from and the operations it may perform.
- An organization can allowlist specific IP addresses. Every allowlist entry requires a written reason and can carry an expiry date, so the exception is documented rather than forgotten.
- Requests are deduplicated, so a retried submission does not create a duplicate record.
Files and attachments
Documents and attachments are held in a private storage bucket and served through signed URLs that expire in minutes to an hour. A link copied out of the product stops working shortly afterwards.
Connecting your own BI tool
If you want to query Alano from your own reporting stack, an admin can issue a per-organization database user. That user is read-only and can reach a set of analytics views only — never the underlying tables. The password is shown once at creation and is not stored by Alano; rotating it closes any live connection first.
Signing in
Alano supports three ways to sign in:
- A one-time code sent to your email address
- Email and password
Two-factor authentication and enterprise single sign-on are not available today. If you need SAML or OIDC against your identity provider, that is part of the deployment conversation.
What Alano staff can reach
Alano operates the platform, so a small number of staff hold administrative access to production for support, migrations and incident response. That access is need-to-know rather than company-wide.
We state this because the alternative — claiming no employee can ever see customer data — would not be true of us or of any hosted product where support can help you recover a record. If your requirements do not allow vendor administrative access at all, the on-premise option exists precisely for that.
Overview | Deployment | Compliance & privacy | Privacy Policy | Chrome Extension Security | Contact