Fixing Workflow Errors with AI

Description

When a workflow step fails or logs a warning, the AI fix assistant reads that error, works out what caused it, and — when the cause is a misconfiguration of the step itself — proposes a corrected configuration and applies it once you approve. It goes beyond explaining the error: it can make the change for you.

It is part of the PlaidCloud AI Assistant and opens from the project’s Log viewer, already pointed at the step that failed. It also opens from a problem in the project’s Weave tab.

Opening the Fix Assistant

From the project’s Log tab, beside the raw log entry:

1. Open the project and click the Log tab.
2. In the log list, select the entry for the step that failed. Its full message — including any traceback — opens in the panel on the right under the Log Message tab.
3. Switch that panel to the AI Assistant tab.

The AI Assistant chat opens already pointed at the workflow and step the selected log entry came from, so it starts diagnosing straight away — you don’t have to tell it which step failed. You can read the raw error under Log Message and chat with the assistant under AI Assistant side by side. For a few common errors its first reply is an explanation instead — see Common Errors.

From the Weave Tab

In the project’s Weave tab, select a problem Weave found and click Fix. The assistant opens in a window of its own, already pointed at the step the problem is about, and starts from the problem as Weave reports it now. See Fix a Finding with the AI Assistant for which findings offer Fix.

How It Works

1. Diagnoses — it reads the failing step’s configuration and the tables and columns it touches, and checks its claims against your data rather than guessing from the error text alone.
2. Proposes — if it finds a genuine misconfiguration, it shows you the corrected step configuration and explains plainly what it changed and why. Nothing is saved at this point.
3. You approve — it waits for your go-ahead in a reply of its own. It cannot propose a change and treat the same message as your approval of it.
4. Applies — once you approve, it writes the corrected configuration to the step, through the same path the step editor uses. What gets saved is the configuration you were shown, and one approval saves it once.
5. Offers a re-run — it asks whether to re-run the step now to confirm the fix. Say yes and it runs the step and tells you whether it succeeded, finished with a warning, or failed again; a new failure is an error it then diagnoses. If the step hasn’t finished within two minutes, it says so, and the result shows in the workflow and the Log tab.

The assistant doesn’t offer a re-run for a step that posts to an ERP system or runs another workflow — re-run it from its workflow, where you choose the ERP posting mode — or when the chat isn’t tied to a workflow, or when your role can’t run workflows. If the workflow is already running, nothing runs and the assistant offers to try again.

Note

The assistant never changes your step without approval, and this is enforced by PlaidCloud rather than left to the assistant’s judgement. It shows the proposed configuration first and applies it only after you explicitly confirm that change in a later message — an ambiguous reply isn’t taken as approval. If it asks you to approve the same change a second time, nothing has been saved yet.

Common Errors

When a step fails with one of these common errors, the first reply is an explanation PlaidCloud already has for that kind of error, so it appears straight away.

On any type of step:

• an expression that uses a column that isn’t in the table the step reads
• a column mapping whose source column isn’t in the table the step reads
• a setting the step needs that was left empty, such as the connection it uses or the table it reads
• a workflow the step runs that failed — the cause is most likely in one of that workflow’s steps, so check that workflow’s log
• a table the step names that can’t be found

On a SQL Extract step:

• SQL that can’t be read as written, such as a misspelled keyword or a bracket that isn’t closed
• a function the database doesn’t recognize
• a table that doesn’t exist
• a function given a type of value it can’t work with, such as adding up a text column (on Databend)
• a value that can’t be converted to the type the SQL asked for, such as text where a number or a date was expected (on Databend)

On a Table Extract step, with fixes that point to the step’s own tabs and fields rather than to SQL:

• a source table that doesn’t exist yet, or no longer does (on Databend)
• an expression that uses a function the database doesn’t recognize (on Databend)
• a function given a type of value it can’t work with, such as adding up a text column in an expression or with Summarize (on Databend)
• a step with no output columns, such as one whose columns were all removed

The explanation says what usually causes the error, which words in the error message to look at, and how to fix it. It is general: it doesn’t check your step or change anything. To have the assistant look at the step itself, reply. From then on it works as described in How It Works, with the explanation as part of the conversation.

Any other error goes straight to the assistant’s own diagnosis. That includes the database errors listed above when they come from any other type of step.

What It Can Fix

The assistant repairs the configuration of the one step the error came from — for example a mistyped column or function name, an invalid expression, a wrong data type or cast, or malformed SQL. It changes the least that fixes the error: one failure, one targeted change, with the rest of the configuration left as it was.

What It Won’t Do

Its only lever is that step’s configuration, and it is upfront when the problem lies elsewhere rather than bending an edit to look like a solution.

• It edits one step’s configuration and nothing else — it won’t create, delete, or reorder steps, create tables, edit a different step, or change your data.
• Many failures aren’t configuration problems: missing or malformed source data, an upstream step that failed first, a transient or infrastructure error, a permissions issue, broken logic inside a transform or UDF, a missing file in a document account, or a resource or timeout limit. For these it explains what it found and points you to where the real fix lives.
• Warnings are often benign and need no change — it will say so plainly rather than invent an edit.
• When it isn’t certain a change will work, it says so and names what it’s unsure about instead of presenting a guess as a certainty.

Note

The fix runs with your own permissions on the current project, so it can only change a step you could already edit yourself — and any change is reversible by re-running the assistant or editing the step directly.

Tips

• The diagnosis is grounded in your live step configuration and table metadata, so it reflects the project as it is now — not a cached or assumed shape.
• After a fix is applied, say yes when the assistant offers to re-run the step, or re-run it yourself, to confirm the error is resolved.
• If the assistant says the cause is outside the step’s configuration (bad data, an upstream failure, a permissions problem), that is the answer — fix it where it actually lives rather than asking the assistant to edit the step anyway.