Who sees what, who did what, what can never be deleted: governance in FlowSharp

Who can see: folder permissions that apply everywhere

In the first article of this series we introduced Jev, the FlowSharp AI that makes decisions and hands the case to a person when it isn't sure. But automating decisions only makes sense if every decision stays traceable, visible only to the people who should see it, and kept as evidence. This article is about the foundations that make that possible, which landed between releases 0.87 and 0.88.

The starting point is simple. When a workflow engine handles contracts, orders, appraisals and AI-assisted decisions, it becomes the place where the proof of how a company works is kept. Compliance officers, the DPO, quality managers and management, especially in regulated sectors such as finance, healthcare, public administration and insurance, always ask the same three questions: who can see this process, who did what, and what can't be deleted. The answers have to come without spreadsheets and without a 'just trust us'. One point of honesty: we don't claim compliance with any specific regulation. We provide tools that help you produce the evidence an audit asks for.

The first answer is folder permissions for flows, on three levels: read, write and manage. They can be assigned to individual users, custom roles and system roles, and they are inherited down the folder tree, so you set a rule once at the top and it applies to everything below.

What matters most is that the rule holds everywhere. Anyone who isn't listed doesn't see the flows, their versions or their running cases anywhere in the product: not in lists, searches, analytics, process maps, exports, integration keys or the assistant. Moving a flow to another folder moves all its versions with it, and running cases follow the new rules immediately, with no window in which something stays exposed by mistake.

Since 0.88.6 there is also a safeguard against slips. Removing the last rule from a folder no longer opens it to everyone: with no rules, only administrators can see it. Opening it up again is an explicit action, confirmed and logged. Folder permissions are a premium feature, which can be enabled per organization.

Who did what: the activity log

The second question is the one an auditor asks first: who did what, and when. In FlowSharp, administrators get an activity log that records, for every event, who did it, when, through which channel (browser, automations or AI assistants) and on which object. You can filter by actor, action, object and period, and export to CSV or JSON, so evidence can be handed to whoever asks for it in the format they prefer.

The log goes beyond data changes. It also records logins, failed logins, two-factor checks, password recoveries, edits to flow drafts, exports and shares. One rule applies across the board: passwords, codes and tokens are never recorded. The log exists to reconstruct what happened, not to create one more place where secrets are stored.

Retention is set per organization, from 30 days to 10 years, and is separate from the retention of cases. You can decide how long to keep the trail of actions independently of how long you keep operational data.

One detail makes a real difference: if writing to the log fails during a sensitive operation, the operation is cancelled. We would rather show a visible error than answer 'done' and leave no trace.

What can't be deleted: protected history and legal hold

The third question is about how solid the evidence is. The case history and the activity log are protected directly in the database: ordinary edits and deletions are rejected, even when they come from a part of the software that should not have allowed them. The only exceptions are planned, logged operations, such as retention-based expiry. Evidence that anyone can quietly correct afterwards is not really evidence.

For situations where you need to freeze things as they are, there is legal hold. An administrator places a case or a process version under legal hold and states a reason. From that moment the case can't be deleted, either by hand or by expiry, its documents can't be erased and the process can't be removed. A badge makes it visible at a glance, and lists have a dedicated filter to find everything under hold. Legal hold is also a premium feature.

Sensitive data, accounts and sessions

Governance is also about where data goes. The designer, and since 0.88.1 the publishing step as well, warn you when a sensitive field leaves for a webhook, event, script or AI model without shielding. It isn't a ban: whoever designs the flow decides with full awareness, and the warning appears when the decision is made, not months later during a review.

For AI models there is a call log that records, for each provider, metadata and the estimated cost. If you choose, it also stores the messages sent and received; with shielding on, those messages contain only pseudonyms. This is the Data Shield we covered in the Jev article, and here it also becomes evidence you can consult.

User access has clear rules too. Ten failed attempts within fifteen minutes lock the account, the last five passwords can't be reused, every web session has a maximum lifetime, and logging out closes all sessions. In their profile, each person sees their active sessions, with device and address, and can revoke them one by one. Administrators get the same list for every user, which helps when an access looks suspicious or someone leaves the company.

For integrators: the same rules for everyone

A permission that only applies in the interface is only half a permission. In FlowSharp, integration keys and the Flow Agent follow the same permissions as users: writing or managing requires the matching level. Through MCP, the Operator and Read-only roles get the same reduced view they would see in the interface.

Credentials written into Webhook tasks are never returned to agents: a placeholder appears in their place. A key restricted to certain flows doesn't see, in the catalog, the tools that would be refused to it, so the agent doesn't waste time trying them, and when an operation isn't allowed it receives the same error codes as the REST API. Integrators can write a single error-handling logic that works on both channels.

Requests to the flow trigger and to the agent tools have a real limit that can't be bypassed, designed to protect the installation from runaway automations or misuse.

Finally, a security audit closed the side doors: related cases, analytics, map comparisons and the extension. The principle we checked item by item is a single one: if you can't see a flow, you can't see it anywhere.

Trust in automation is built on traceability

Our motto is still 'measure first, then automate', and governance is its natural complement: you can automate with confidence when you know who can see what, you can reconstruct who did what, and you are sure the evidence won't change. Jev can make decisions because each of them leaves a trace that holds up over time.

In the next article of the series we'll look at processes you can package up and carry from one installation to another: another way to make work repeatable, verifiable and truly the company's own.