How is a system built that delivers both business agility and regulatory compliance?
In the procurement and vendor management software market, feature lists are easy to compare — workflow, approvals, reports. What's harder to see, but decisive in the long run: how is the system built internally? What guarantees does the platform provide, and what is left to user configuration?
The difference is not theoretical. In regulated industries — finance, manufacturing, pharma, public sector — every procurement decision must be auditable. DORA (Digital Operational Resilience Act), NIS2, and GDPR impose specific requirements: who saw the data, who decided, based on what rule, and can all of this be retrieved two years later. If these guarantees are implemented at the application level — process by process, block by block, separately — then every new feature introduces additional compliance risk. If, however, they are implemented once at the platform level, business users can configure freely without compromising security guarantees.
Fluenta One is a cloud-native, multi-tenant B2B SaaS platform whose architecture is built on this separation. The entire infrastructure operates in the EU (Azure North Europe), with exclusive EU data residency.
The platform distinguishes between two types of processes, and this distinction shapes the architecture.
Vertical processes are the primary channels of business value creation. They follow a concrete business goal: clear starting point, endpoint, measurable outcome. Examples: Procure-to-Pay (from procurement to payment), Order-to-Cash (from order to revenue), Contract Lifecycle Management (full contract lifecycle). These processes manage transactional state — a purchase request, a quotation, a contract.
Horizontal processes are the organization's cross-functional capability layer. They don't create business value on their own, but every vertical process relies on them. Examples: supplier validation, authorization management, compliance verification. These manage system-level state — whether a partner is active, whether a rule is in effect.
Fluenta One handles horizontal processes natively, at the platform level. This means that when a vertical process (e.g., purchase request approval) stalls because a supplier's tax ID has expired, the platform automatically initiates the appropriate horizontal process (supplier validation), then continues the original vertical process after successful completion.
The system is divided into two layers that are clearly separated — and with them, the responsibilities as well.
L0 — Platform Layer: IT and Fluenta's responsibility. This layer guarantees the security boundaries that no one can breach. It includes everything that ensures security, data isolation, and auditability:
Business users never modify the L0 layer directly — and that's the point. L0 controls are automatically enforced for every process configured in the L1 layer.
L1 — Business Logic Layer: procurement's freedom. This is where processes can be configured without involving IT for every change. Drag-and-drop editor in Fluenta Business Designer, configurable blocks, decision tables, form builder. L1 blocks use L0 services transparently — users don't need to know that a policy engine runs in the background, an audit log is being written, and tenant data is isolated.
The practical consequence: the procurement team can independently modify an approval level or add a new form field, and platform-level security guarantees remain automatically in effect. No IT ticket is needed for every change, but compliance controls cannot be compromised.
In Fluenta One's L1 layer, processes are built from Smart Blocks. Each Smart Block is internally one or more BPMN (Business Process Model and Notation) steps packaged together; externally, a configurable box on the drag-and-drop canvas.
Blocks fall into six categories:
Every block is configured in a no-code manner: trigger type, artifact template, artifact mode (create, update, read), optional timer with escalation path, external connector integration. The configurator writes no code — they define relationships between blocks.
Beyond custom building, Fluenta One's Blueprint system enables deploying complete, production-ready process packages to a tenant in a single step.
A Blueprint contains the complete BPMN orchestration process assembled from Smart Blocks; pre-defined artifact templates (purchase request, quotation, contract); user task forms with field-level configuration; decision tables (amount threshold → approval level, priority → SLA); notification templates; escalation configuration; and role-based permissions.
During Blueprint Adoption, the tenant admin selects a blueprint, and the system creates a complete copy in the tenant. From there, it can be freely customized: adding blocks, modifying form fields, adjusting approval levels, swapping connectors. The blueprint is a starting point, not a rigid template — but both paths receive the same L0 platform guarantees.
A few examples: the Sourcing Blueprint guides the process from request to contract, the Quoter Blueprint provides simplified quotation requests for lower-value purchases, and the Supplier Qualification Blueprint handles supplier qualification, document collection, and compliance verification.
Traditional workflow systems move documents — files that must be opened, extracted, and processed manually. In Fluenta One, the Business Artifact (structured data package) is a structured record that travels through the process and is enriched at every step.
The artifact has three properties that are critical from an audit perspective:
Queryable — no need to extract files or dig through email chains. Data can be queried structurally: how many purchases over 10M HUF were approved in Q3? The answer is available in seconds.
Composable — the output of one step automatically becomes input for the next. The request amount triggers the decision engine, which determines the approval path — without human intervention.
Immutable and versioned — every modification creates a new version; the previous one remains. While anyone can overwrite a cell in Excel after the fact, the artifact guarantees that what the auditor sees is the unalterable truth.
Version control is two-tiered. Minor version (v1.1, v1.2) for every in-process modification, major version (v1.0 → v2.0) only when the artifact transfers to a new process instance's ownership. This model ensures that auditors can always trace what happened to the data, when, and by whom.
Regulated industries typically require multi-party processes. In a sourcing process, the buyer and suppliers work together, but their data must remain separated. Traditional solutions — emailing, shared portals, custom integrations — none provide both audit trail and true data separation.
In Fluenta One, cross-tenant collaboration is not an add-on — it's a natural consequence of the architecture. The CrossTenantGateway ensures that every cross-tenant request passes through the system in a controlled manner: sensitive fields are automatically masked (hidden) from the target organization, access is granted through time-limited tokens, and a complete audit trail is generated from both parties' perspectives.
Three data access patterns are supported. Form Copy provides simple data exchange: the form definition and initial data are copied to the target organization, where they fill out their own instance. Service Gateway is used for real-time shared data, such as in bidding or auctions. Granted Project enables ad-hoc sharing in partner or subsidiary relationships.
Real-time communication is provided by Fluenta Messenger: cross-organizational messaging, Collaboration Rooms for joint work, and cross-tenant notifications — all with L0 security guarantees.
Fluenta One provides three decision engines because not all decisions are alike. From the procurement leader's perspective, the key point is: the system automatically applies the appropriate method to the given problem.
Strict rules for clear-cut cases (DMN Engine). If the amount exceeds 5M HUF, CFO approval is required. If the priority is "urgent," the SLA is 24 hours. These rules are configured in decision tables, without code, and the output is always predictable — the same input always produces the same output (deterministic, meaning reproducible and auditable).
Complex compliance logic (Policy Based Decision Engine). When a decision depends on multiple factors simultaneously — supplier risk classification, contract value, category, geographic location — rule tables are not enough. The policy engine considers the full context, but the output remains deterministic: it's traceable which rule the decision was based on.
Intelligent analysis for complex problems (AI Decision Engine). Document analysis, risk assessment, anomaly detection — where patterns need to be recognized, not rules followed. The AI engine makes probability-based recommendations, but an artifact-level record is created for every activation: what input, what output, when. AI helps, but control and accountability remain.
The choice between engines is made during process design: the configurator determines which engine activates at each decision point.
A concrete scenario helps illustrate how all of this works together. A procurement manager submits a 15M HUF purchase request:
Throughout the entire process, the user only sees their own tasks — platform-level controls operate automatically.
The platform complies with multiple compliance frameworks:
Tenant isolation is guaranteed at the platform level — not at the application level, where it could be circumvented. In practice, this means one tenant can never see another tenant's data, even in cases of misconfiguration, because isolation is enforced both at the database level (Row-Level Security, i.e., row-level access control) and at the policy engine level.
Network security follows a Zero Trust model: all communication is authenticated and encrypted; the system trusts nothing by default. Pod-to-pod communication is protected with mTLS, databases are accessible only through private endpoints, and a WAF (Web Application Firewall) operates in the production environment.
The central principle of Fluenta One's architecture: security guarantees are implemented at the platform level, not per process. The L0 layer — IT and Fluenta's responsibility — provides tenant isolation, audit logging, authorization, and encryption. The L1 layer — procurement's freedom — carries the business logic: Smart Blocks, Blueprints, artifacts, decision tables.
This separation means the procurement team can independently configure processes, and platform-level security guarantees remain automatically in effect. Compliance is not an afterthought that must be assembled separately before every audit — it's a natural consequence of the architecture, operating at every moment.