Skip to content

Create User Onboarding Workflow with Power Automate

Picture of Catherine Han

One major work I've done recently was optimizing the user onboarding journey for Flow Studio. Here's an overview of the key objectives I aimed to achieve:
1. Welcome Email for Trial Subscribers

2. Information Pack for Paid Subscribers who converted from Trial to paid subscription

3. Notification for Unconverted Trial Users about free license benefits

4. Survey Email for Cancelled Subscribers

5. Documentation of Communication History in a system

6. Notification for Multiple Trial Initiations 


We explored various CRM tools for this task, but cost was a significant factor. In the end, we decided Power Automate is still the best solution for our needs. (Sorry, HubSpot, but your Marketing professional pack's monthly price tag of $1000+ just wasn't feasible for us!)

Now, let's walk you through the Flow I crafted:

Part 1: Basic Setup

  • Create the trigger When an HTTP request is received: This allows the webhook (from the event source, which is Stripe where the subscription trial/start/cancel takes place) to initiate the flow. No need to input a POST URL here; upon saving the flow for the first time, the POST URL (Endpoint) is automatically generated to link with the source.

  • Add Endpoint to the source: Similar to many platforms that provide webhooks, this step involves adding the Endpoint URL from the previous step to the source platform for the webhook. Configure the events you want to listen to. Here's an example for Stripe:

Once these steps are completed, your Flow will be triggered whenever a desired event occurs on the source platform.

Part 2: Collect/Format key data 

When a webhook is triggered, it passes through a JSON with extensive data, but only a few fields are relevant to our use. To address this, I created a Scope containing multiple Compose actions to collect and format the key data required.

Note that instead of creating a ton of Compose actions as I did, you can also use a Parse JSON action to define multiple properties in one go, like this:

Additionally, as the webhook event doesn't provide the user email (required for sending emails) but rather the system user ID, another scope is created to obtain the associated email addresses via an HTTP GET API request. Subsequently, another Compose action is used to specify the email property.

 

At times, a user may have multiple subscriptions, and we aim to avoid sending multiple emails if the user initiates additional subscriptions. Therefore, another API executed by HTTP is used to retrieve all active subscriptions of the user and count the number of subscriptions.

Part 3: The Decision Tree

With our preparations complete, we now set up the logic to determine whether an email should be sent, and if so, which one.

  • The top layer of the decision tree is based on the event type from the webhook, categorized as follows:    
    1. Subscription created    
    2. Subscription updated    
    3. Subscription deleted
  • Using a Switch control, we evaluate the 'Event' value (derived from our multiple Compose actions in Part 2) for each of the three cases: created, updated, and deleted.

In the case of Subscription Created:

  • If the event is subscription created, and the subscription status is "trialing," and it's the only subscription for the user, then we send the trial welcome email:

  • There are several options of sending emails in Power Automate. The one I displayed here is  drafting the template and saving it to an Outlook folder. Then, I set up the Get emails (V3) action to search for the template in that specific folder by the email's subject line. Finally, I use a Send an email (V2) action to send out the email to the email address obtained in Part 2.

 
However, I'm considering switching to SendGrid to send emails via API, allowing me to track email opens. 

After sending an email, I use another Compose action to record the date of the email sent.

And then I log the recipient, subject, and sent date into a SharePoint list with an Add item action.

  • On the other branch of the decision tree for Subscription Created, we encounter scenarios where a user starts a subscription without a trial, which is rare due to our payment settings. Alternatively, a user who is already on a subscription may start another one inadvertently, leading to potential double charges. To address these situations, we trigger another Send an email (V2) action to notify ourselves.

In the case of a Subscription Updated:

  • There are numerous events fall under this category, such as monthly updates for subscribers. However, our focus here is specifically on instances where a user transitions from a trial to an active (paid) subscription. We establish the following conditions:

    1. Current subscription status = active
    2. Previous subscription status = trial
    3. Current count of subscription = 1
  • Utilizing a similar process, we send an email from a template stored in Outlook and log the details into the SharePoint List.

In the case of Subscription Deleted:

  • To begin, we must confirm that the user no longer holds any subscriptions. This verification process can be achieved using a Switch or a Condition action to check if the subscription count equals 0.
  • Next, determine if the cancellation occurred during a trial period. This involves employing a Condition to assess if the cancellation request time or the cancellation occurrence time falls within the trial period, which spans from the trial start to the trial end. However, this step requires some adjustments from Part 2, as cancellation-related timestamps could be empty, leading to Flow encountering an error. Similarly, for older users who never underwent a trial, trial start and trial end timestamps would not exist.
  • To address these scenarios, if the cancellation occurrence time is missing, I substitute it with the cancellation request time, and vice versa:
  • In cases where the trial start or end time is missing, I replace them with 0. This ensures that the cancellation time would never fall within the trial period during the calculation process:
 
  • When the condition is satisfied (cancellation occurs within the trial period), we send a notification email to the user. Conversely, when the condition is not satisfied (cancellation occurs outside the trial period), we send a survey email to the once-paid subscriber.

In wrapping up, crafting this user onboarding journey has indeed been quite the adventure! It involved navigating through numerous trial and error moments, where the Snapshot function in Flow Studio became my saving grace, allowing me to revert the Flow to its previous version and correct the missteps along the way.

If you have any questions or comments, please feel free to share them below. Your input is greatly valued and appreciated!

 

Catherine works behind the scenes at Flow Studio; she wears a multitude of different hats.  She is project manager, product manager, customer advocate, data analytic, marketing manager and sales manager.   She is fiercely data driven and loves how Power Automate can be used to integrate our systems together.  

Catherine uses Flow Studio's snapshot feature to restore flows, and her user onboarding flows are business critical.  They support the back systems that runs Flow Studio the startup company.

She owns Learn Flow Studio, the website and all the blog content here, follow her story to learn more of the backstory of how we are putting our startup together.