Sub-procedures let you break complex Fin Procedures into smaller, focused flows. They help keep your main procedure easy to follow while allowing you to reuse logic and reduce duplication.

You can think of sub-procedures like helper functions in code: Fin runs them top to bottom, then returns to the parent procedure.

Key benefits and use cases

Improve readability by hiding detailed logic behind clear, named steps.
Reuse logic across multiple points in the same procedure.
Simplify maintenance by editing shared logic in one place.
Increase reliability by isolating complex or failure-prone steps.

How sub-procedures work in Fin

Sub-procedures behave like a nested list of steps inside a procedure.

Fin executes the sub-procedure from top to bottom.
After completion, Fin returns to the next step in the parent procedure.
You can exit early using /End sub-procedure.
Sub-procedures can be nested inside other sub-procedures.

Shared context and isolation

Shared context: Connector outputs, attributes, and user responses are visible across the parent and its sub-procedures.
Isolation: Data does not persist outside the parent procedure (for example, when using /Switch procedure).

Note: Sub-procedures are scoped to a single parent procedure and cannot be reused across different procedures.

How to create and run a sub-procedure

Create a sub-procedure

Open or create a Fin Procedure from Fin AI Agent > Train > Procedures.
Navigate to the left-hand menu.
Click + New sub-procedure.
You’ll be redirected to a new sub-procedure editor.
Enter your steps and give the sub-procedure a clear name.

You can rename or delete a sub-procedure by hovering over it in the same menu.

Run a sub-procedure

Open the parent procedure from Fin AI Agent > Train > Procedures.
Type / to open the command menu.
Select Run sub-procedure.
Choose the sub-procedure you want to run.

Fin will execute the sub-procedure and then continue with the remaining steps in the parent flow.

Tip: Use /End sub-procedure to return early, similar to a function return in code.

Best practices for using sub-procedures

Use sub-procedures for meaningful logic

Sub-procedures are most effective when they encapsulate clear, reusable logic.

Effective usage:

Complex branches that would otherwise clutter a condition.
Repeated logic used in multiple places within a procedure.
Escalation or handover flows that need consistent behavior.
Failure-prone steps that benefit from isolation and testing.

Less effective usage:

Single, trivial actions that don’t need reuse.
Logic that fits cleanly inside one /Instruction or /Condition.
Excessive fragmentation that forces constant context switching.

Keep sub-procedure chains shallow

Avoid deeply nested chains like sub-procedure → sub-procedure → sub-procedure where possible.

Note: Deep nesting does not impact Fin’s performance, but it makes procedures harder to read, debug, and maintain.

Name sub-procedures clearly

Use descriptive, action-oriented names that explain what the sub-procedure does.

Good examples:

CollectPaymentInfo
VerifyUserIdentity
ResolveDeliveryIssue

Avoid names like:

Step4
PartB
HandleRefundSectionA

Clear names make the overall flow easier to scan and understand.

Example use cases

Abstracting complex logic from the main flow

Sub-procedures can hide detailed checks or validations so the main procedure stays readable. For example, checking whether a customer’s insurer is supported can live in a dedicated sub-procedure instead of cluttering the primary logic.

Reusing shared handover logic

If multiple parts of a procedure require the same escalation or handover process, placing that logic in a sub-procedure ensures consistency. When updates are needed, you only have to change it once.