Updated on by Daniel Twigg
Even with a fully fledged embedded integration platform in your development toolkit, you still need a little planning to create effective, high functioning, integrations. The devil is certainly in the detail. In this blog we look at some of the areas you should consider before beginning a new integration build.
Like any development, working without a plan will never give you the results you were expecting.
Just because you’re using a visual language tool to create and manage processes, you shouldn’t skip using your most valuable tool: pen and paper.
A quick sketch identifying data sources, logic/data orchestration and objectives can make the world of difference when it comes to building efficient and resilient integrations.
Knowing your Use Case
If you’re building integrations between your SaaS and an array of third party applications you already have a head start – you already know how your own users interact with your application and the data contained therein. You are already one step up the ladder.
This gives you a quick start for:
- Selecting what data you need to access for the integration
- How to attribute records within your application
- Working out if the integration will be triggered by polling or an event driven webhook
With those in mind, you can convert the conceptual idea behind each of your use cases to practical, pseudo-integrations that break down the individual steps needed to take to achieve your integration’s goals.
Or better yet, draw out a flow chart of the process you are aiming to automate. Being able to visually look over your automation is a huge advantage when laying up your integration, or considering the next step…
Identifying Methods to Use
Every SaaS application has its own particularities, which can lead to inconsistencies when making assumptions on the API capabilities of applications in the same vertical markets.
While one application may opt to complete a task using a polled method, such as Get New Contact, another platform may choose to offer the same service through a Webhook event. While the difference may be subtle, it may affect the choices you make while designing your integration workflow.
In order to prepare you can check what methods are available inside Cyclr on our connector pages. If you can’t find the method you need in a connector just contact us and we can get it added for you.
What User Experience do you want to Provide?
How your users are able to self service their integrations can play a role in deciding what types of integrations you create.
Users are always going to have to have some input when it comes to setting up an integration. Whether it’s simply authenticating a service, selecting a data source or defining a logic step for data manipulation/orchestration, their input is what will transform a templated integration into a valuable business automation resource.
How you facilitate this user input is flexible with Cyclr; build your own UI on top of our API or use our trigger-based, quick setup solution – LAUNCH. However, it is something to take into account early on, when building your integration templates.
Building anything too complex, covering too many applications in one integration, can be too niche for wider user base adoption and confusing for the average user to set up.
The other side to this, is that you create thin integrations which, while easy for a user to set up, don’t offer the functionality required of a time-saving, essential integration.
So how can we meet users in the middle to provide a better user experience?
Pre-Mapped Fields vs User Set
Rather than leaving all fields to be set and configured by your user, you can pre-map fields.
You can do this for any field where you know that the required data is always coming from the same data source – just select the source (which can be any step used in your integration template to the left of the step you are configuring the fields for) and the field within it
The Many or The Few
While Cyclr don’t limit the number of steps, or number of applications for that matter, you can use in your integration templates, you may want to ask yourself what’s best. You could build a library of many small but functional integration workflows, or fewer large workflows that cover several stages of a process, but which approach is better?
Your use case will dictate which approach should be appropriate, however if you can choose, often creating a wider range of focused integration workflows is better. While this may mean that your users have to install more integrations to do what they want, this approach can offer advantages including:
- Enhanced integration management (easier to bug fix and update)
- Wider adoption (some customers only want to use a small part of an integration, to be able to pick and choose allows them to create their own automation stack)
If all of this sounds a bit much then you can always get in contact for some advice. A member of the Cyclr team is there to help, just click on the chat button ——->