4 min read.
Every time your integration executes a workflow based on the logic you have defined for it, it’s a run. Typically, an integration is designed in a way that it achieves a number of things such as a trigger executed, a conditional logic met, a filter applied, some data mapped and eventually, an action occurred. All this is included in a single run. It’s easy to understand, simple to calculate, and convenient to sell to your end-users.
Measuring Your Runs
Let’s say you have designed a great workflow that keeps your customers’ contacts in your app in-sync with a CRM (e.g: Pipedrive). This means that every time a new contact is created in your app, that contact is also created in Pipedrive in real-time, reducing a significant amount of app fatigue for your customers.
Every time this workflow is executed, 1 run is consumed.
Now suppose your user (let’s call them Maria) has 500 records of contacts in their HubSpot account. Maria connects their HubSpot account to your app to perform a first-time bulk import. Upon connecting the integration for the first time, all these contacts will be imported to your customer’s account in your app. This bulk import is performed in pages (aka pagination).
Each third-party app has a different number of records of contacts per page that they process through their API. On average, the number is 100 records of contacts per page which is what we process at Integry via bulk import per page. To import 1 page of contacts, Integry consumes 1 run from your plan.
So when a bulk import takes place, the number of runs that would be consumed to import all their contacts from HubSpot would be:
500 records/100 records per run = 5 runs
Here’s an example of what a workflow could look like which would consume 1 run every time it’s executed:
Managing Your Runs
While runs make it convenient for you to predict what your usage would be like, there are methods through which you can ensure that your users are using integrations fairly. It is a common practice to apply limits on users as to how many runs can each user consume in a month. This helps you predict usage, control costs, and even monetize on your power users who may have heavy usage.
For example: If you have 3 different pricing tiers, you can apply varying limits on users belonging to each pricing segment. The least paying gets less number of runs and high paying users get more runs. Limits are applied on a monthly basis and reset at the start of every month.
What happens if all my runs are consumed?
If your users end up consuming all your runs before the end of a month, we auto-subscribe you to a Bundle of Runs add-on. Your prorated bill is generated based on brackets of 20k runs, additionally consumed. Each bundle of 20k runs is priced at $100 and billed at the end of the month.
A good way of thinking about pricing for runs is to figure out how they can help improve your bottom-line and increase revenue. We’ve written some strategies for you to consider adding integrations to your pricing.
If you have any queries drop us a line at firstname.lastname@example.org.