Workflow Review — User Guide
Accessing the Review
The workflow review is located in the Production Readiness section of your thunk, under the Review tab.
Open your thunk and navigate to the Production Readiness section in the left navigation
Select the Review tab
Click Run Review to generate a new review (or Re-run Review to refresh an existing one)
The review runs in the background. You'll see a progress indicator showing which step is currently being reviewed. When complete, the report appears on the same page.
Each review is saved as a versioned artifact — previous reviews are retained, and the most recent one is displayed automatically. You can re-run at any time to get an updated assessment after making changes to your workflow.
What the Review Does
The workflow review analyzes your workflow's configuration and step instructions to surface potential reliability issues. It checks properties, tools, step bindings, instruction quality, and environment configuration — providing feedback intended to help you build more reliable workflows.
The review is advisory. It highlights areas that may need attention, but not every finding requires action. Some findings are hard failures (a required connection is missing), while others are softer guidance (instruction style could be clearer). Use your judgment about which findings to act on.
When to run a review:
After initial workflow setup, before going to production
After significant changes to step instructions, property bindings, or connection configuration
When troubleshooting unexpected workflow behavior
As a periodic health check on production workflows
Understanding the Report
The report is organized into sections, each covering a different aspect of your workflow. Here's what each section means and how to interpret its findings.
Summary
A table at the top of the report showing the issue count for each area and each step. This gives you a quick overview of where to focus your attention. An issue count of 0 means that area passed all checks.
Environment
Checks your thunk's operational environment configuration.
Resource environment — Production workflows should use a shared environment rather than a Personal environment. A Personal environment depends on one person's connections (OAuth tokens, API keys), which creates a single point of failure.
Admin coverage — Production workflows should have at least 2 people with admin or owner access. This ensures someone can manage the workflow if the primary admin is unavailable.
Status Transitions
Checks that your workflow steps' status transitions follow the correct order defined by the Status property's enum values. Each step transitions from an initial status to a final status, and these should form a consistent chain matching the Status property's value order.
If this check fails, the findings will indicate which steps have status transitions that don't follow the expected order. Status transition issues may require assistance from a member of the Thunk team to resolve, as they can involve constraints in the workflow orchestration system.
Properties
A table reviewing each user-defined property in your workflow's data schema. Two checks are performed on each property:
Description Present — Every property should have a description so the AI agent understands its purpose. Properties without descriptions force the agent to guess from the name alone, which is unreliable.
Type Match — The property's description should be consistent with its configured data type. For example, a property described as "a link to the company website" should not be configured as a Text type when the dedicated URL type exists. If the description implies a list of values but the property is not configured as a list type, this will also be noted.
The Step References column shows how many steps use the property as an input or output binding. A count of 0 indicates the property is not referenced by any step — it may be unnecessary and could be removed, or it may need to be added to at least one step's bindings.
The Notes column shows the reason for any failures. Each property row includes an Open link that navigates directly to that property in the planning view.
Tools
Reviews the tools available to your workflow's AI agent. Only user-defined tools are included — custom tools, MCP server tools, Generic API tools, and imported thunk tools. Platform-provided tools are excluded since their implementation cannot be modified.
Two checks are performed on each tool:
Strict Schema — Tools with strict schemas constrain the AI agent to produce well-formed arguments, improving reliability. Non-strict tools allow the agent to pass under-constrained arguments, which can cause errors.
Naming — Tool function names should follow snake_case convention (lowercase letters, digits, and underscores). Non-standard naming can reduce reliability because LLM function-calling is optimised for snake_case names.
Steps
Each workflow step is reviewed across several dimensions. Every step heading includes an Open link to navigate directly to that step in the planning view.
Human-in-the-loop
Reports whether the step requires human intervention — through approval gates, manual assignment, manual start, or tools that need approval. This is informational, not a pass/fail check.
Scheduled
Reports whether the step has a recurring schedule configured. This is informational.
Detected Intents
Shows what the review system detected the step is doing based on its instructions. A step may have multiple intents, a single intent, or none. Possible intents include:
SendMessage — The step sends a message to an external party via a communication channel (email, chat, or conversation property)
ReceiveMessage — The step receives or waits for a response from an external party via a communication channel
ReadFromStorage — The step accesses a file from an external storage system (Google Drive, OneDrive, SharePoint)
WriteToStorage — The step uploads or creates a file in an external storage system
WebSearch — The step searches the web for information
The current set of detected intents is limited but will grow in future updates to cover more workflow patterns. These intents drive the Tool Configuration checks below.
Bindings
Checks whether the step's input and output property bindings are justified by its instructions. The review classifies the connection between each bound property and the step's instructions into one of six evidence types:
name — The property name appears literally in the step instructions (case-insensitive, flexible whitespace, hyphen-insensitive). For example, "Contact Email" matches "contact email" or "ContactEmail"; "Move-In Checklist" matches "move-in checklist" or "move in checklist". This is the strongest evidence and is determined programmatically before the LLM is consulted.
description — The step instructions closely match the property's description, but the property is not mentioned by name. For example, instructions that say "update the qualification status" match a property described as "Whether the lead is qualified."
entity-reference — The property name combines an entity with an identifier suffix (e.g. "Company Name", "Document Title", "Order ID") and the step instructions reference that entity (e.g. "the company", "the document", "the order") without using the full property name. The property is needed to identify the entity being discussed.
implicit — The step instructions imply the use of this property, but connecting them requires at least one reasoning step beyond direct name, description, or entity-reference matching.
satisfies step intent — The property is not referenced in the step instructions, but it satisfies a detected step intent. For example, a Conversation property bound as output satisfies the SendMessage intent even if the instructions don't mention the conversation property by name.
not justified — No connection found between the property and the step instructions, and the property does not satisfy any detected intent. These bindings are flagged as potentially unnecessary.
The bindings section displays a table showing every bound property, its direction (input or output), and the evidence type. Below each property, the specific phrase from the instructions that connects to it is shown in italics. This transparency lets you see exactly why each binding was classified the way it was.
The summary line shows:
all justified — Every bound property has a name, description, entity-reference, implicit, or intent-based connection
N potentially unnecessary — Some bound properties could not be connected to the instructions or any detected intent
Note that the accuracy of this check depends on the clarity of your step instructions. Vague or ambiguous instructions may result in false positives — a property binding flagged as unnecessary when it is actually needed. If you see a binding finding that you believe is incorrect, consider whether the language in the step instructions pertaining to that property could be made clearer. Using the exact property name in your instructions is the most reliable way to ensure the connection is recognized. A false positive is often an opportunity to improve the step's instructions so the agent (and the review) can better understand the relationship between the instructions and the bound properties.
Extra Properties
Flags any step that uses the "Extra Properties" catch-all property in its input or output bindings. Extra Properties is a fallback for data that doesn't have its own explicit property — its use suggests the data model should be refined with dedicated properties.
Data flow
Checks that every input property is available when the step runs. An input property must be either a workflow input (provided at the start) or an output of an earlier step. If a step tries to read a property that no prior step has produced, the data won't be there.
There are exceptions to this rule. For example, if a step is scheduled (runs on a recurring timer), it may legitimately read a property that it also writes — each scheduled execution reads the value from the previous run and updates it. The review accounts for this case and will not flag scheduled steps that use the same property as both input and output.
Retry safety
Checks whether automatic retry is safe for this step. Steps that send messages or write to external storage have side effects that would be duplicated on retry (sending the same email twice, creating duplicate files). If retry-on-error is enabled on such a step, this check flags it.
Tool Configuration
Checks whether the step has the connections it needs to do what its instructions describe. This is driven by the detected intents:
Intent requirements — For each detected intent, shows whether it is satisfied. For example, a step with the WriteToStorage intent needs a file storage connection (Google Drive, OneDrive, etc.) to be enabled.
Enabled Connections — For each enabled connection, shows which intent motivates it. Connections with no motivating intent may be unnecessary.
Target platform
Checks whether step instructions reference a specific cloud platform (by URL) that isn't enabled. For example, if instructions contain a Google Drive URL but only OneDrive is configured, this check flags the mismatch.
Instruction quality
Checks the style and structure of step instructions against best practices:
Sequential work — When a step involves multiple activities, they should be structured as numbered sections with descriptive titles, not written as unstructured prose.
Conditional clarity — Conditional logic should place the condition (antecedent) before the action (consequent). Patterns like "Only do X for Y" or "Do X when Y" place the action first, making it harder for the agent to follow.
Timeout handling — If instructions include timeout-related language, it should use a clear conditional pattern like "If you run out of time, finish the step and move on." Vague time pressure language ("try to finish quickly") is not actionable.