Back to app
What's configurable per client

What's configurable per client

The exact per-organization configuration surface — pipelines, statuses, roles, vertical vocabulary, Experience Modes, feature flags, branding, and booking pages — and the deliberate boundary at customization.

Reviewed AdminVertiqa 1.61+

Vertiqa is tailored per client through configuration. Everything below is set per organization, in settings, with no code and no separate build. This is the surface you work with on an implementation.

What you configure per organization

  • Pipelines and stages. Each org defines its own sales pipelines and stages — the shape of how they sell.
  • Task statuses. Delivery and task workflows use per-org statuses.
  • Roles and permissions. Role-based permissions with granular permission codes, managed by the client's own admins.
  • Entity vocabulary via vertical packs. A pipeline pack brings a vertical's language and pipeline shape — for example whether the commercial document is an estimate, a quote, or a proposal — so the product speaks the client's trade. Packs can be started from a gallery or built for the org.
  • Experience Modes. The same workspace presents as Full (the complete app) or Simple (a focused daily assistant) so you can match different users' sophistication without splitting the data. See Getting started for how the two relate.
  • Custom fields. Add the custom fields a client needs on their records.
  • Per-org feature flags. Modules and capabilities can be turned on or off for an organization, so a client only sees what they've bought or need.
  • Branding. Per-org co-branding on outbound email and on public booking pages, so the client's customers see the client's identity.

The boundary: configuration, not customization

Everything above is configuration. What Vertiqa does not do per client:

  • No per-client database schema changes.
  • No bespoke, code-written workflows built for a single client.
  • No forked or separately deployed build.

That boundary is intentional. It keeps every client on one well-tested, continuously updated platform instead of a set of one-off systems that drift apart and can't be upgraded together.

When a client wants something outside the boundary

Two honest paths:

  1. It's already configurable — the need maps to an option you haven't used yet. Most "can it do X" questions land here.
  2. It's a genuine gap — then it's a product request, not a custom build. If it's broadly useful it ships to every client; if it's truly one client's idiosyncrasy, that's a fit conversation worth having early rather than a promise to engineer around.

Setting this expectation up front protects both you and the client: nobody is waiting on a custom build that was never going to happen.

Was this helpful?