Updated on by Daniel Twigg
GDPR has seen a major swing of power towards users with regards to their data. As well as enforcing companies to tighten up their data policies and become more responsible for their users’ data, it also means that users should have improved mechanisms for requesting, removing and editing their data. As a client of Cyclr you are probably using Cyclr to deliver integration solutions to your own end-users, helping them connect your own app with third-party apps. However there is no reason that you can’t use Cyclr to enable some of your own internal processes, GDPR compliance being one of them. Call it a ‘bonus’!
While many of these features may be deeply embedded within many SaaS applications settings, we’ve devised an alternative approach.
We’ve created a workflow, using Cyclr, that provides users’ subscription statuses via email, all from a form entry.
Let’s take a look.
While this workflow may look confusing at first look, don’t be scared, it’s really 4 sections that I’ll walk you through so you can create your own.
The Initiation Stage
The first stage sets up the whole process. It uses a form entry to trigger the workflow (in this case we are using Contact Form 7), which creates a new row in a Google Sheet to temporarily store the results of the next stage.
The Service Checker Stage
While this may look like the longest and most confusing of the stages, it is really a short, 4 step workflow used 3 times (as we are checking 3 different services in this example).
This is the process for checking one system for a contact.
We are querying the application with the email address received from the contact form submission to see if it exists in the system (in this case Pipedrive).
We then use a decision step to split the workflow based on if the email address is found in the system or not. Depending on if it is or isn’t the Google Sheet is updated with a “yes” or “no” using the Google Sheets connector and “Update Cell” method.
You can repeat this process for all of the systems you want to check, ensuring to connect both Google Sheets steps to the start of your next checker block.
The Notification Stage
In this stage we are adding the details collected in the Google Sheet to our email service provider, in this case Sentori. We’ve created a custom list, including additional field for each application that is checked through the workflow.
A contact is created in this list, with the stored results of the system checker being added to the record. These fields can then be mapped to an autoresponder template within Sentori (we’ll cover more of this later).
This stage is completed by sending the autoresponder template, complete with the data requested by the user, back to the form submitter.
Closing The Loop
Finally, we don’t want to be keeping any more user data than we need to. This is why we are closing the loop of the entire process by removing the users data from the Google Sheet and email list.
We’ve started with a delay step to ensure the data can be properly processed and sent to the user before it’s removed. This is followed by removing the row that was created in Google Sheets.
The final step is an internal step to see if the user is already on another email list. If they are, they are just removed from our subscription checker list. However if they aren’t, they are removed entirely from our email service provider.
The User Experience
For simplicity, the user enters their email address and receives an email giving them all of their subscription information. This email also includes links allowing them to alter their subscription status for each service with one click.
This is made possible due to Sentori giving you the ability to trigger a workflow based on a click within an email. This powerful feature mean there are many different ways you can handle your users’ requests, which we will dig into further in a separate article.