Task-based, process-based and evidence-based approaches — and why BOAT is the future
The software industry's workflow tools have evolved along three fundamental paradigms. Each approach answers a different question, centers on a different element, and supports organizational needs to varying degrees: process consistency, transparency, decision traceability, and cross-organizational collaboration.
These needs affect every company, but they are especially critical in regulated industries — banking, insurance, public sector — where audit and compliance requirements are legal obligations.
The market reflects this shift. In 2023, Gartner renamed the BPM category from iBPMS to BOAT (Business Orchestration and Automation Technologies). BOAT is not just a new marketing term: it signals that software is no longer just a "process diagram" but an active command center that coordinates procurement with the ERP, legal systems, and AI capabilities. The emphasis is moving from static process modeling to intelligent, event-driven orchestration — real-time coordination across systems.
The central element is the ticket. The system answers the question: who is doing what. Each task is a standalone unit: it has an assignee, a status, a deadline. The connections between tickets are weak — dashed links, epics, labels — but these don't enforce sequence or data flow.
The audit trail is essentially a log of status changes and ticket comments. These are retroactive and manual: when the auditor arrives, you prove the process ran correctly with screenshots and exports.
Typical tools: Jira, Asana, Linear, ClickUp, Monday, Trello.
The task-based approach works well where the question is simple: done or not done? In a development sprint or a marketing campaign checklist, this is enough. But once the question becomes which rule governed the decision, who approved it, based on what data, and whether all of this is retrievable six months later — the ticket-based approach has no answer.
The central element is the workflow instance. The system answers the question: how is the process progressing. A path defined in a standard process model, with conditional branches and automated steps. It ensures strong consistency: every procurement request, contract signing, or vendor onboarding follows the same defined path, with automatic audit trail.
Typical tools: Camunda, Pega, ServiceNow, Kissflow, Bizagi.
The process-based approach tells you how the process is progressing — but not what was produced along the way. If the auditor asks what data informed the decision and where the evidence package is — the answer is usually that it's in another system.
The central element is the artifact — a structured data package containing all relevant information from a process step or decision: filled fields, approvals, references, timestamps. It's not a document in the traditional sense, but a machine-queryable record. When the auditor asks "what was the basis for this decision?", the artifact is what you can produce at the push of a button — the complete evidence package.
The evidence-based approach is strong for regulatory compliance: versioned, immutable (once recorded, it cannot be retroactively "adjusted") data records that prove the decision chain. Its weakness: the process itself is often weak or manually assembled.
Typical tools: this approach rarely appears as a single product — it's typically assembled ad-hoc from multiple tools: DMS systems (OpenText Documentum, SharePoint), GRC modules, and CLM platforms' evidence management features (DocuSign CLM, Icertis).
The evidence-based approach knows exactly what data came together and who decided — by version, with timestamps, retrievably. But when it comes to how that data got from point A to point B, through which steps, under which conditions — the answer is often a spreadsheet or a manually assembled email chain.
The Fluenta One platform combines the strengths of all three approaches in a single, integrated solution. While in Jira a procurement is just a "sticky note", in Fluenta One it's a live process where the complete evidence package can be produced for the auditor at the push of a button. Three pillars make this possible.
Orchestration is more than process automation: it's like a conductor who not only leads their own orchestra but sees and coordinates external systems as well — the ERP, legal platforms, financial approvals. The Fluenta One workflow engine ensures that every business process (procurement, contracting, vendor onboarding, compliance check) runs as a defined, re-runnable workflow. Conditional branches, parallel execution paths, human tasks, and automated steps combine to make the process consistent and auditable.
The Fluenta One artifact engine generates a structured data package as the outcome of every process step. The artifact has three properties:
Queryable — no need to unpack files or dig through email chains; the data is structurally queryable. For example: how many procurements over 10M HUF were approved in Q3?
Composable — one step's data package automatically becomes input for the next step. The request amount triggers the decision engine, which determines the approval path.
Immutable + versioned — every data package is recorded immutably, linked to its process instance. No "adjustments", no retroactive changes.
Fluenta One's architecture doesn't force every decision through the same engine. Instead, three complementary decision mechanisms handle different situations:
DMN Engine (Decision Model and Notation 1.3) — a business rules engine that stores rules in decision tables. In practice: this is what determines whether CFO approval is automatically required above 5 million HUF, or which supplier category requires a three-quote process. Configurable from the admin interface, no developer needed.
Policy-Based Decision Engine — directs decisions based on the full workflow context, not static if-then rules. Useful when decisions depend on multiple factors simultaneously: supplier risk classification, contract value, category, geographic location. Deterministic and auditable — every decision is traceable.
AI Decision Engine — for highly complex, non-deterministic problems. The AI here is not a "black box": it's like a digital assistant that performs analysis and makes recommendations, but the final decision is made by the established business rules and humans. AI helps, but control remains.
A parallel paradigm shift is underway in the software industry, with direct implications for business platforms. Three principles are crystallizing in AI-based (agentic) software development.
First: natural language is enough to build software, but not enough to govern business decisions. AI can generate working code from English-language prompts. But business rules — who approves what, under which conditions, with what accountability — require a precision that natural language cannot provide. A prompt is not auditable, not versioned, and not deterministic.
Second: automated proof artifacts must verify that the implementation matches the specification. In an AI-driven world, trust comes from ex-post verification — machine-generated evidence that the output conforms to the rules.
Third: the future is multi-agent — some agents execute, others verify. This separation maintains reliability and accountability.
Fluenta One's architecture is built precisely on these principles: the DMN Engine and Policy-Based Decision Engine execute deterministic business logic; the AI Decision Engine can serve as an independent verification or optimization layer; every decision automatically generates a structured artifact that proves compliance.
The three workflow paradigms each solve one piece of the puzzle: task-based tracks the who, process-based tracks the how, evidence-based tracks the what. None of them answers all three questions on its own.
Fluenta One is the platform where these three layers — workflow orchestration, evidence generation, and formal decision logic — are not modules bolted together but a single architecture. The result: every business process simultaneously executes, documents itself, and proves its own compliance.