How we built a Fin Task for Incident Management | Community
Skip to main content

This Fin Task was designed to help customers quickly understand whether an issue they’re experiencing is related to a known incident, without needing to contact support directly. The goal was to make it feel fast, human, and reassuring while surfacing relevant technical information from our infrastructure.

 

🌍 Step 1: Detect the Customer’s Hosting Region

We start by detecting the customer’s data hosting region, which is stored as a company-level attribute in Intercom. This attribute is critical — it allows the task to tailor its response and status checks to where the customer's workspace is hosted.

Regions we support include:

  • US
     
  • Europe
     
  • Australia
     

If the region attribute is missing or unrecognized, the task defaults to US, and clearly explains this fallback behavior in the customer message (without speculating or misleading).

 

🔌 Step 2: Query the Incidents API via Region-Specific Data Connectors

For each supported region, we’ve set up a dedicated Fin Data Connector that calls our internal Incidents API. This API is the source of truth that powers our public status pages, and allows us to fetch structured data about any currently active incidents.

  • US → https://www.intercomstatus.com/us-hosting
     
  • Europe → https://www.intercomstatus.com/eu-hosting
     
  • Australia → https://www.intercomstatus.com/au-hosting
     

When Fin runs this step, it queries the API in real time to check for any active incidents tied to that hosting region. If one is found, the incident details (title, impact, status, etc.) are surfaced directly to the customer through Fin in a clear, easy-to-understand format.

 

💬 Step 3: Present the Results Through Fin

The logic then branches based on what the Incidents API returns:

  • If a relevant incident is found:
    Fin presents the incident details and ends the task.
     
  • If no active incident is found:
    Fin:
     
    • Informs the customer that no current issues have been detected.
       
    • Shares the relevant status page link to give customers transparency and context on past incidents - since incident.io doesn't currently offer an API endpoint for historical incidents, this link serves as the best source of that information.
       
    • Asks a clarifying question to better understand the customer’s specific issue.
       
    • Ends the task immediately after sending this final message.
       

We’ve also enabled Fin to follow up after the task ends. This is important for two key reasons:

  1. If there is an active incident, the customer might still have questions. Letting Fin continue the conversation after the task ends gives them space to follow up without interruption.
     
  2. If no incident is found, the clarifying question invites the customer to explain their issue, and since the task has ended, their reply is now directed at Fin in a natural, conversational way. This improves continuity and allows Fin to handle follow-up questions more fluidly, without being tied to the structure of the original task.
     
  • If region is unknown:
    The task:
     
    • Defaults to checking the US region.
       
    • Lets the customer know this is the most common region and we’re using it as a fallback.
       
    • Shares the US status page link.
       
    • Ends the task.

 

Hi ​@Karl O' Sullivan - 

This is awesome. I’m trying to do something similar, and I was wondering how you phrased your trigger instructions? I’m finding it hard to isolate the Task to things that could be large scale incidents, vs. things that are normal errors/require standard troubleshooting. 

Hi ​@Karl O' Sullivan - 

This is awesome. I’m trying to do something similar, and I was wondering how you phrased your trigger instructions? I’m finding it hard to isolate the Task to things that could be large scale incidents, vs. things that are normal errors/require standard troubleshooting. 

​@Isabel L. It can be a bit of an art form with the current data connectors, but I think the prompt and Guidance are your best friends here -- the newer Fin Tasks features that are rolling out give you a lot more control of the flow of this but there’s a lot you can do with the existing setup.   I have a client with something similar currently, we also do some similar things with cancelation workflows and pre-production workflows where tasks check on the status of an order to see if it can be canceled or not based on where it’s at in the production workflow. 

Happy to chat if I can be helpful here, feel free to DM or book a time on my calendar.  From what ​@Karl O' Sullivan shared above, it looks like this is using Fin Tasks which has the ability to break the actions down together in a Tasks workflow with step by step instructions which is more robust than the current Fin Custom Actions (which is now labeled Fin Tasks in the UI but most people don’t have access to the full new version yet I believe it’s currently under managed availability you’ll need to ask your Account Manager. )

Hope this helps!

Hey @Isabel L. — +1 to everything the wonderful Nathan said above. Just a quick note on the trigger logic: we provide the context directly in the task instructions for when we want it to fire. In this case, we’ve centered the context around wider platform issues (e.g., “is Intercom down”). This ensures the task won’t trigger if a customer only mentions a single, isolated issue rather than a potential widespread problem.

Hi ​@Karl O' Sullivan, when will the tasks feature be available for all users?

Terms & ConditionsAccessibility statement