You've set up the Prismatic embedded integration marketplace and have several integrations published to it. For some of those integrations, you have a general idea of their statuses because your onboarding and support team members are the ones who must deploy and delete those integrations for your customers.
However, to lessen the work for your teams, you also have other integrations set up for customers to activate and deactivate themselves.
NOTE: An integration deployed for a single customer is called an instance. And while your team members can deploy and delete instances for customers, your customers perform the equivalent by activating and deactivating instances. To keep things simple, we'll use the terms "activate" and "deactivate" for the balance of this post.
In both cases, you'd like an automated way to track the status of instances, seeing that the status drives the following critical processes for your teams and your app:
- Accounting – To ensure accurate billing, it is likely that your accounting team needs to know when an instance has been activated and deactivated.
- Onboarding and support – These teams need to know what instances have been activated and deactivated to train and support the customer for those instances properly.
- Your application – For export integrations, your app may need to know if a given instance should be receiving data from it.
Fortunately, you can use two types of triggers to notify your teams and your app of instance status changes. These are the instance deploy and instance remove triggers.
Understanding instance deploy and instance remove triggers and flows
The instance deploy and instance remove triggers help manage the execution of an instance. As a result, they are also called management triggers. Each trigger starts a flow (a series of steps/activities).
The instance deploy trigger runs when a member of your team (or a customer) activates an instance. This trigger starts a flow that is useful for tasks such as setting up third-party webhooks, setting up third-party permissions, and defining a folder structure in a file storage system.
Here's an example of an instance deploy flow that sets up needed file folders, tells the app to start sending data, sends an email to support, and sets up the subscription in the billing system:
The instance remove trigger runs when a member of your team (or a customer) deactivates an instance. This trigger starts a flow that is useful for undoing what was done in the instance deploy trigger flow. Instead of setting up a webhook or permissions, it can tear down or remove them. In general, think of the instance remove trigger flow as the functionality that cleans up after an instance has been deactivated.
In addition to the capabilities we just listed, you can set up each trigger flow with steps to notify your team and your app when an instance is activated or deactivated.
Here's an example of an instance remove flow that removes no-longer-used file folders, tells the app to stop sending data, sends an email to support, and cancels the subscription in the billing system:
If you want to break out the logic, you could set up multiple instance deploy flows for various tasks. For example, you could use one to set the app to send data, another to let the billing app know that the subscription was turned on, and a third to notify members of your team via a messaging app that the instance was activated.
Now, on to the benefits of using these triggers.
Accounting benefits
Chances are, you need to know what integrations are activated for each customer so you'll know how to bill the customers. Perhaps you charge a flat fee per month, or maybe you prorate the charge based on the number of days in the month the instance was activated, or you could be using an entirely different billing metric.
Whatever the details of your billing process, you need to know what instances were activated and deactivated (and when) for each customer to ensure that you are billing them accurately.
To do this, you can set up actions to notify your API when integrations are activated or deactivated or even can set up the triggers to connect directly to common billing apps such as Stripe or QuickBooks using the built-in components.
Onboarding and support benefits
It's essential for those in your company who are setting up and supporting your app (and your integrations) to know which customers are using which integrations.
A simple way to notify your teams when an instance is activated or deactivated is to use the built-in Slack or Amazon SES components to send a message that [Customer] activated XYZ integration.
If you track which integrations are active within your app, then the instance deploy and instance remove flows can notify your app directly of the change in status. Then your team can see which instances are active for each customer by looking it up in your app.
Tracking the status data in your app can be particularly helpful when a customer calls in and says that an instance isn't working. Before your support team starts troubleshooting, a team member can check the app to see if the instance is currently activated.
App benefits
As noted earlier, tracking the integration status in your app makes it easy for your team members to see the status. In addition, for export integrations, your app needs to know where and when to send data. If your app supports webhooks, then it makes sense to set up the webhook in the instance deploy trigger and tear down the webhook in the instance remove trigger.
If you are using a shared endpoint setup, your app might need to know to start sending data for User ABC to that shared endpoint. You can set up that action in the instance deploy flow as well.
Pausing an instance or changing an instance configuration
If a member of your team (or the customer) pauses an instance and then unpauses it, the instance deploy trigger does not run again since the system does not interpret a pause as the instance being deactivated.
However, if you change the instance configuration or increment the integration version, the system requires that you resave and re-activate the instance, causing the deploy trigger to run again. To avoid problems with doing this, you'll want to ensure that the instance deploy flow is idempotent.
Conclusion
Using instance deploy and instance remove triggers with your integrations lets you and your systems stay current with instance statuses automatically while simplifying several vital business processes.
If you would like to know more about setting up instance deploy and instance remove triggers to track the status of your instances, please contact us.
