Using Fin Tasks, you can give Fin custom instructions on the task you want it to perform. We've prepared some good examples which you can check out below:

You can template the instructions with data, instruct Fin to run actions, store action response data, reply to users, and reference content from your knowledge base (coming soon).

A good prompt can make a major difference in how your Fin Task performs.

Before we dive into the specifics of tips and how to formulate best Fin Tasks, here are some helpful tips that generally apply when working with large language models (LLMs).

For some additional reading, see the introduction topics here.

It is very important to make sure that each “Give Fin a Task" block should perform one task and one task only. If you need to do a lot, it may be better to split the prompt into more Fin Tasks.

One clear and significant benefit from splitting your prompt into multiple Fin Tasks is the ability to specify output variables and collect their values as mandatory requirements for finishing a task. These can then be used in a later Fin Task, allowing for greater control over whether and how they get used in this task.

Let’s imagine we have a task where we want to fetch all orders on a specific date. We could:

For example, a task that handles both collecting date and filtering in one task would look something like this:

While the task that has 2 separate blocks, one for date collection and one for order processing might look something like this:

The two solutions are very similar, but with two important distinctions:

While this is a simple example where it might be fine to use just a single block, it clearly shows the benefits of using more but simpler tasks to achieve a greater level of control over the process and greater assurances over the reliability of execution.

In this section we provide what we believe to be a useful mental model to have when building a Fin task prompt.

Tasks serve as a guide to Fin rather than a strict execution plan that must be followed. Fin will choose the best step depending on what is happening.

Task Goal and Guidance

Define the overarching purpose of the task, i.e. what the task aims to accomplish. This goal sets general behaviours you want Fin to display that are applicable to many or all steps of the task execution.

As an example, the goal around a refund task could be set as follows:

Required Attributes

Identify the input values needed to perform the task. Explicitly state in the prompt:

If we continue with our previous example, attributes might include a purchase date, a transaction ID, or the reason for the customer requesting a refund.

Execution Plan

This is a clear, logically-complete, step-by-step plan that Fin should follow. Make sure to cover all the decision rules that are necessary for Fin to perform the task, otherwise Fin might hallucinate those rules.

The best and easiest way to formulate these is to follow an “if + else” logic. This logic guarantees you will always be able to make a decision at any stage and either make progress towards a solution or have a way out of the process if you are stuck. For our example, this would look like:

If the logic and information Fin needs to access is too open-ended, you should consider whether you can break down the Fin Task block into smaller blocks with more well-defined, constrained logic that can go in the prompt.

Completion Definition

Clearly define what counts as completion of the task. Make sure the task description clearly and explicitly communicates when the overall task is complete.Specify the conditions under which the task can be considered to be completed, regardless of it producing a positive or negative outcome for the customer.

An example of this would be:

If possible, you should also include information about any task attributes/attributes required by the task. If the output variable you are trying to fill in is e.g. refund_outcome, add:

We have compiled a number of different use case prompts below that can help you shape your Fin Tasks.

All of them should be preceded by a “Give Fin a task” block (or more than one, depending on the use case) that collects some data from the user such as order or member ID or a reason for refund/cancellation.

The goal of this task is to determine if a refund request made by a customer is valid, and if so, process it. By following the below instructions, you will be able to verify and process a customer’s refund request for orders made with Company X.

Then you will think step-by-step to strictly complete the below execution plan:

Step 1:

Use action get_order_details for order with ID value_of_collected_order_id_attribute to retrieve details for that order. Then follow the below logic to determine whether the retrieved order can be refunded:

a) If the order date is more than 30 days older than the present date, inform the customer you cannot offer a refund because the order was initially made more than 30 days ago. You can do this by marking the task as completed with refund_outcome set to denied and informing the customer of the outcome. This is your last step.

b) If the order date is less than 30 days older than the present date, proceed to Step 2.

c) Else, you should inform the customer you cannot verify whether the order can be refunded and escalate to a human member of the support team. You can do this by marking the task as completed with refund_outcome set to escalation and informing the customer you have taken this action. This is your last step.

Step 2:

Use action process_items_refund and provide it with the order ID value_of_collected_order_id_attribute to process a refund for that order. Then gather the response and:

a) If the refund has succeeded, inform the customer that the refund was processed successfully. You can do this by marking the task as completed with refund_outcome set to success and informing the customer of the outcome. This is your last step.

b) Else, if the refund has failed, inform the customer you were not able to process the refund. You can do this by marking the task as completed with refund_outcome set to escalation and informing the customer you have taken this action. This is your last step.

You will have completed this task when, following the logic specified above, you have determined the current step to be your last step, either because you have decided that the refund cannot be processed, because you have successfully processed the refund, or because you have escalated the refund request to a human member of the support team.

Mark the task as complete when you have enough information to fill in the value of the refund_outcome output variable with a status of either denied, success or escalation, respectively. No other value is valid.

The goal of this task is to determine if a subscription cancellation request made by a customer is valid, and if so, to process it. By following the instructions below, you will be able to verify and cancel a customer’s subscription for Company X.

Then you will think step-by-step to strictly complete the below execution plan:

Step 1:

Use action get_subscription_details for the subscription with ID value_of_collected_subscription_id_attribute to retrieve details for that subscription. Then follow the below logic to determine whether the retrieved subscription can be canceled:

Step 2:

Use action cancel_subscription and provide it with the subscription ID value_of_collected_subscription_id_attribute to process the cancellation. Then gather the response and:

You will have completed this task when, following the logic specified above, you have determined the current step to be your last step - either by deciding that the subscription cannot be canceled, successfully canceling it, or escalating to a human member of the support team. Mark the task as complete when you have enough information to fill in the value of cancellation_outcome with either denied, success, or escalation. No other value is valid.

The goal of this task is to determine if a requested shipping address update for a customer is valid, and if so, to process it. By following the instructions below, you will verify and update the shipping address in Company X’s system.

Then you will think step-by-step to strictly complete the below execution plan:

Step 1:

Use action get_customer_profile by providing the ID value_of_collected_customer_id to retrieve the customer’s current account status. Then follow the logic below:

Step 2:

Use action validate_address by providing the value_of_collected_new_address to verify its authenticity and deliverability. Then follow the logic below:

Step 3:

Use action update_customer_address by providing both value_of_collected_customer_id and value_of_collected_new_address to finalize the address update. Then follow the logic below:

You will have completed this task when, following the logic specified above, you have determined the current step to be your last step - either because the address request was denied, successfully updated, or escalated to a human support agent. Mark the task as complete when you have enough information to fill in the value of the address_change_outcome output variable with a status of either denied, success, or escalation. No other value is valid.

The goal of this task is to determine if a customer’s request for a loyalty points adjustment is valid, and if so, to carry out that adjustment. By following these instructions, you will review the customer’s loyalty account status, validate the request, and then adjust the points accordingly in Company X’s system.

After gathering these details, think step-by-step to strictly complete the execution plan below:

Step 1:

<Use action get_loyalty_profile> with the ID <value_of_collected_loyalty_member_id> to retrieve the member’s account status. Then follow the logic:

Step 2:

Use action audit_loyalty_activity by providing value_of_collected_loyalty_member_id and value_of_collected_points_adjustment_request to review recent loyalty transactions and see if the request is justified. Then:

Step 3:

Use action adjust_loyalty_points by providing value_of_collected_loyalty_member_id and the value_of_collected_points_adjustment_request amount to finalize the points adjustment. Then:

You will have completed this task when the logic above leads you to your final step - either denying the points adjustment, successfully applying it, or escalating to a human agent. Mark the task as complete when you have enough information to assign the points_adjustment_outcome a final value of denied, success, or escalation. No other values are valid.