Product · 4 min read

Describe the process, watch it take shape. And know what reaches the model

October 16, 2026

Create with AI shows the flow as it is built, lets you retry a single step and keeps a record of every call. Reserved fields are shielded before they reach the model.

From description to Draft: structure first, details after

Whoever has to set up the first process usually has it all in their head and nothing on the canvas. Create with AI starts from there: you describe the process in plain words and watch it take shape. The flowchart does not arrive in one piece. Phases and connections appear first, then activities, assignees and expected times.

The order has a practical reason. Once the structure is on screen you can already judge whether the sequence makes sense, before the details arrive. The Draft can be opened in the Designer as soon as the structure is ready, without waiting for generation to finish. Management and process owners can correct course early, on something concrete, instead of assessing an answer that lands all at once.

The Draft remains a starting point to review, not a finished process. For integrators the gain is a shift in time: less on the initial model, more on connecting to the systems, which is where the process meets the reality of the company. For work inside the Designer, see «Il Visual Flow Designer»; here we stay with guided construction.

When generation hits a problem: retry only the step

A generation can run into a problem. What matters is what happens to the work already done. If one step fails, only that step is retried, and what has already been saved stays.

If the generation as a whole fails, the flow already created is not deleted. You can choose Retry, or Open in the Designer to fix it by hand. This is not a promise that every attempt will succeed. It is a limited, checkable guarantee that a hiccup does not force you to start over.

For a process owner, that is the difference between a tool you can use in a meeting and one that makes you rewrite the description every time something goes wrong.

Copilot and default rules: checks before changes are applied

Changes proposed by the Copilot go through a check too. Before applying them, FlowSharp verifies that every field respects the database limits. If something exceeds them, the Copilot is told and corrects it on its own.

A save can still be rejected. When that happens, the reason appears in the conversation, together with a «Correggi automaticamente» (auto-fix) button. The outcome is not buried in a technical log: the person working sees it.

The same applies to inconsistent default rules. Create with AI and the Copilot correct them and show the adaptations applied, so you can see what was changed compared with what was proposed. Automatically generated activity codes stay short and readable, a small detail that helps when the flow has to be read by someone who did not build it.

Shielding: what reaches the model and what does not

For DPOs and IT, the question is simple: which data goes out to the model? Reserved fields are always replaced by placeholders before they reach the AI, even when free-text anonymization is switched off. In other words, shielding of reserved fields does not depend on that setting.

The return path works the same way in reverse. Placeholders returned by the model are restored only in the reserved fields. The model therefore works on placeholders, and the real values come back only in the reserved fields.

One boundary is worth keeping in mind: free text has its own anonymization setting, separate from the shielding of reserved fields. Whoever is responsible for the data should check how it is configured, and look in the log at the fields that were actually shielded.

AI Log: checking what happened, call by call

A reliable feature is one you can reconstruct after the fact. In the AI Log, administrators can filter flow design calls in a dedicated channel. Correction calls are visible as well. For each one you can see the author, the flow when known, tokens, latency and outcome.

What stays on record depends on the level chosen on the provider: metadata only, or prompt and response as well. It is a configuration choice and should be made deliberately. With metadata only you can reconstruct who called the model, when and with what outcome, but not the content exchanged.

In practice, three checks are enough to get started. First, open the dedicated channel and compare the calls with the flows that were created. Second, verify the retention level set on the provider. Third, look at the shielded fields in the log and compare them with the list of fields your company considers reserved. This stays within the logic of «measure first, then automate»: first you see what the AI does, then you decide how much to entrust to it. For the broader picture, see «AI governata: portare l'intelligenza artificiale dentro processi controllati».