This article covers practical examples of how to structure your steps, conditions, and data connector calls in Fin Procedures.
Structuring Instruction steps
The Instruction step is the default and most powerful step.
Combine related actions into one step
Fewer, well-designed steps that coherently combine related actions are better than many separate, small steps.
❌ Less effective:
Step 1: @read Email.
Step 2: Ask for email if it's not there.
Step 3: @use get_subscription_details
Step 4: Send a reply listing every API field.
✅ More effective:
@read email.If it is not known, ask the user for their email before continuing. Then @use get_subscription_details and reply asking the user what they need help with. Include the user's current plan, plan status, and next renewal date in your reply.
Be clear and complete
Think of Fin as a new teammate with no prior context. If a human couldn’t easily understand your instructions, Fin likely won’t either.
❌ Less effective:
Collect the customers order number and make sure it is valid and not a tracking number
✅ More effective:
Collect the customers order number. If they provided a number but it is longer than 11 characters excluding the # at the start, let them know that it may be a tracking number and ask them for the order number again. If the customer can not provide their order number do not continue @Escalate:Support team.
Adding notes for teammate context
Use @Add note within an instruction step to leave internal context on the conversation. This is especially useful before escalations or handoffs, giving teammates the context they need.
❌ Less effective:
Step 1: @use Get_Order_Details and tell the customer the status.
Step 2: If the order is lost, @Escalate to Support team.
✅ More effective:
@use Get_Order_Details and tell the customer the status. If the order shows as lost or undelivered past the expected delivery date, @Add note with the order number, shipping provider, expected delivery date, and current tracking status. Then @Escalate to Support team.
Using the Condition step
Conditions tell Fin how to behave in different situations. You can use them for major, distinct forks in your logic.
Example: Code condition for refund eligibility
This example uses a Code condition to check the output of a data connector.
IF: data["Check refund eligibility"].decision == "eligible"
Let the user know that their subscription is eligible for to be refunded. Present pausing as an alternative: "If you'd prefer, you can pause your subscription instead of canceling — that way you won't need to pay a restart fee if you decide to return later." Confirm if the user would like to continue with the refund or pause their subscription.
If the user wishes to continue with their refund then @Use Process refund to complete the refund. Once complete let the user know the refund has been processed and the funds will be in their account typically within 7-14 days.
ELSE:
Let the user know their subscription is not eligible for a refund. @Tag Not refund eligible.
Offer them the option instead to cancel their subscription and that this will pause any future payments.
@Escalate to Support team.
Example: Natural Language condition for fulfillment status
This example uses Natural Language to check an attribute.
IF: @Read Fulfillment status is 'fulfilled'
Notify the customer that their order cannot be canceled, as it has already been fulfilled.
@End Fin continues
From here, you can click the + icon to Add else if condition or Add else.
Working with data connectors and attributes
You can use data connectors and attributes to get or update information.
Calling a data connector
You can instruct Fin to use a data connector to get or update information from an external system.
Example: @Use: Get order status and tell the customer what the status of their order is.
Letting Fin gather inputs
You don't need to explicitly tell Fin to gather data that a connector needs. Fin infers the inputs it needs to collect based on the connector's setup.
❌ Wrong (unnecessarily complex):
First ask the customer for their email, then call @get_order_details with that email
✅ Simple and clear:
Call @get_order_details
Reading data from a connector
When you use a data connector, the returned data is available throughout the Procedure. Use @read attribute to access this data in later steps instead of calling the same connector again.
❌ Less effective (slower):
Step 1: @use Get_Subscription_info and include @read plan status in your response
Step 2: @use Get_Subscription_info and include @read refund eligibility in your response
Simple and faster:
Step 1: @use Get_Subscription_info include @read plan status in your response
Step 2: include @read refund eligibility in your response
Reading an Intercom attribute
You can also read Intercom data like People, Company, or Conversation attributes.
Example: Tell the customer their @Read People.Plan
Using Sections
Sections let you organize a Procedure into named, logical blocks. By default, Fin executes steps from top to bottom regardless of section boundaries — sections don't change execution behavior unless you direct Fin to jump to one.
Example: Organizing a returns procedure with sections
Break a longer procedure into named sections to improve readability and make it easier to navigate with Go to section.
Section: Verify order
@use Get_Order_Details. If the order is not found, let the customer know and @End Fin continues.
Section: Determine return type
Ask the customer if they'd like a refund or an exchange.
IF: the customer wants a refund
Go to section: Process refund
ELSE:
Go to section: Process exchange
Section: Process refund
@use Process_Refund and let the customer know the refund will arrive in 7-14 days. @Add note with the order number and refund amount. @End Fin continues.
Section: Process exchange
Ask the customer which item they'd like instead. @use Create_Exchange and confirm the new order details. @End Fin continues.
When to use sections vs sub-procedures
Use sections to organize the flow within a single procedure. Use sub-procedures when the same logic is reused across multiple procedures or when you want to encapsulate a complex piece of logic that has its own inputs and outputs.
Using sub-procedures
Sub-procedures are reusable sets of steps that can be called from another Procedure. This is recommended for complex or repeated logic.
Example: Running a sub-procedure in a condition
You can run a sub-procedure as part of a conditional branch.
IF: the customer's choice is to return the item and get a full refund
Send the link https://... to download the return label, and explain that they will get a full refund after the shoes have been returned within 3-5 days.
ELSE:
@Run sub-procedure Send return label & give discount code
Naming sub-procedures
Use clear, action-oriented names that communicate what the sub-procedure does.
✅ Good names:
CollectPaymentInfo
VerifyUserIdentity
ResolveDeliveryIssue
❌ Bad names:
Step4
PartB
HandleRefundSectionA
Using the Ask Teammate step (Human-in-the-Loop)
The Ask Teammate step lets Fin pause mid-procedure and request input from a human teammate — without handing off the entire conversation. Use this for high-risk, sensitive, or complex decisions where you want automation most of the time but still need a human at key points.
Example: Refund approval above a threshold
Step 1: @use Check_Refund_Eligibility. If eligible, @read refund amount.
IF: data["Check_Refund_Eligibility"].refund_amount > 500
Let the customer know their refund request is being reviewed and they'll hear back shortly.
Ask Teammate: "Customer is requesting a refund of @read refund amount for order @read order number. Reason: @read refund reason. Please approve or deny."
ELSE:
@use Process_Refund and let the customer know the refund has been processed. Funds will arrive in 7-14 days.
How Ask Teammate works
When Fin reaches the Ask Teammate step:
Fin pauses and sends a note to the assigned teammate with the context you've configured.
The teammate sees the conversation in a dedicated Needs teammate input view in the inbox.
The teammate can either submit a response (Fin resumes the procedure using their input) or take over the conversation entirely (Fin stops).
If no one responds within the configured timeout, Fin sends an escalation message to the customer and assigns the conversation to your escalation team.
Tips for Ask Teammate
✅ Provide clear context in the note — Include the specific data points the teammate needs to make a decision (e.g., refund amount, order details, customer history).
❌ Don't use Ask Teammate for routine decisions — If the logic can be expressed as a condition or code check, use those instead. Reserve Ask Teammate for genuinely ambiguous or high-stakes situations.
Switching between Procedures
You can direct Fin to move from one procedure to another when the customer's needs change mid-conversation.
Using @Switch for deterministic switching
Use the @Switch command within an instruction step to explicitly move to another procedure.
Example:
If the customer says they'd like to cancel their subscription instead of updating their payment method, @Switch to the Cancellation procedure.
Using Agentic Switch for automatic switching
When Agentic Switch is enabled, Fin can autonomously switch from the current procedure to another live procedure if it determines the customer's intent has changed. Fin makes this decision based on the conversation and procedure trigger descriptions, and may ask clarifying questions to disambiguate.
Agentic Switch is opt-in and can be enabled from the procedure settings. You can still use @Switch for deterministic control alongside Agentic Switch.
Using other steps and guidance
Use Guidance for overall rules and End steps to tell Fin what to do next.
Procedure Guidance
Use the Guidance section for global rules on how Fin should interact during this Procedure.
Example: "Never bring up a refund unless a customer mentions it first."
End steps
End steps tell Fin that the Procedure is finished and what to do next.
Example (Pass to reusable workflow): If the customer still does not provide the order number, then @Pass to reusable workflow Agent Handover.
Example (End and escalate): @End - Escalate to Support team
Example (End and let Fin continue): @End - Let Fin continue
Tips for building better Procedures
Use AI-powered review before going live
After building your procedure, use the AI-powered procedure review to check for potential issues in your instructions. The review analyzes your steps and flags problems that could cause Fin to not reliably follow them. This is a quick way to catch issues before your customers encounter them.
Use version notes and rollbacks
When publishing changes to a live procedure, add a version note describing what you changed. If something goes wrong, you can view your version history and roll back to any previously live version directly from the procedure page.
Example (End with a message): @End with the message "Thanks for reaching out! If you need anything else, just message us again." This sends a closing message to the customer before the procedure ends.
Example (End and close conversation): @End - Close conversation. This ends the procedure and automatically closes the conversation.
Example (End and create a ticket): @End - Create a ticket using the "Bug Report" ticket type. This ends the procedure and prompts the customer to create a ticket, then passes the conversation to a teammate.
Need more help? Get support from our Community Forum
Find answers and get help from Intercom Support and Community Experts