When integrating with Cloud Elements you have two paths you can choose, internal or external. In other words, will the business logic of the integration live inside your application (internal) or inside the Cloud Elements platform as formulas (external).
There are some pros and cons to each approach. The purpose of this article is to make it clear which path to choose for your integration needs.
In general, the decision should be made based on the following question: Do you have a place to put the integration logic in your own application? If you do, put it there (internal integration). If you don't, that is why Cloud Elements provides the formulas option (external integration).
If you have an application that stands on its own and you have access to the source code, the integration logic should always be put there.
Use Case Example
Let's walk through a use case. You have a marketing platform and you want to pull in contacts, generate a lead score and push the lead score back to the original endpoint. Then ongoing, if a contact is added on either the endpoint or in your system you want to generate a lead score for that contact and make sure its up to date in both systems.
Let's solve this use case with both an internal and external integration to illustrate the pros and cons. I want to illustrate that while doing an external integration may be tempting (because you don't need to host the code) it will cause far more complexity and should be avoided if possible.
Putting this logic in your application involves automating authentication. For example, you must save the instance token and instance id relative to each user in your database. Then, to do an initial sync, you must call the APIs to bulk download contacts from the endpoint and save them in your database. Afterwards, you generate the lead score in your own system and then bulk update each contact back to the endpoint.
After the initial sync, if a contact gets added in your system, create it on the endpoint. Likewise, subscribe to events so you will be alerted if a contact gets added at the endpoint.
This method allows you to have complete control over the flow, and more importantly you don't have to worry about race conditions.
Because the integration is external, your application needs a public facing API. That API has to support bulk uploads, bulk downloads, bulk upserts or high enough rate limits to be able to handle each record one at a time, and webhooks/polling. If you support all that, we can get started and a new element can be created for your API.
Now, how are your customers going to configure this if its not in your UI? You can use Element Connect, a UI we built just for this.
For the formulas, you need one formula to do the initial bulk download from the endpoint to bulk upload into your system. Next, you need a formula to upsert the lead score you generated back to the endpoint. This will have to run on a cron, once a day is probably what I would recommend.
To handle any updates, you need two more formulas to watch both sides of the integration for changes to contacts. This is where it gets crazy, for each event you get from either side, you need to query the other system to see if that contact already exists and if it needs to be updated. There could be an infinite loop if you are watching events on both sides. To add more complexity, how will you handle getting an event for each record once a day when you send back the lead scores?
Finally how will you deal with logging? What if your users want to see a log for all the contacts synced?
I think you get the point, we can discuss actually solving this in a different article. For now I will leave it at: Do an internal integration if possible, otherwise keep external integrations as simple as possible.