Solution Instance trigger 1.0
Receive and respond to data generated by any of your End Users' Solution Instances
Basic UsageCopy
The Solution Instance Trigger is a very powerful tool which allows you to receive and respond to data generated by any of your End Users' Solution Instances
It works when:
config or auth data of an instance is updated
an instance is enabled (but not when it is disabled)
The following are examples of when an End User's Solution Instance might initiate the Instance Trigger:
An End User runs the Config Wizard for the first time and their Instance is then enabled
An End User re-runs the Config Wizard to modify a piece of Config Data
Using updateSolutionInstance to import config data updates
This trigger works on a Project/Solution level, as it is tied to the config data and auths of the End Users of your Solution.
The following screenshot shows the output schema of the Solution Instance data that is available from the trigger:
So you can see that it is possible to grab any updates to config data and use this in whatever way you need.
The following workflow shows a very simple example of a solution which contains an instance trigger workflow:
In this case an example snippet of data returned from the GraphQL mutation can be used to update the End User's department:
1"configValues": [2{3"externalId": "external_salesforce-userid",4"value": "\"CJ03928fh293hfH\""5},6{7"externalId": "external_salesforce-department",8"value": "\"marketing\""9}10],
Advanced setupsCopy
You could also set up a more complex data syncing operation. An example setup might be the following:
An initial sync is made when the instance is created, configured and enabled (using the Solution Instance Trigger)
Another workflow is setup to run a sync every certain number of hours (using a Scheduled Trigger)
Another workflow is triggered when an End User clicks on a 'sync' button available in the interface of your integration (using a Webhook Trigger)
The following screenshot shows how you might set up the Solution Instance Trigger workflow in this setup.
As you can see it waits for the data to exist in the service which the End User was setting their config data for before calling a callable workflow to make the required sync:
The callable workflow can be set up like a programming function/method which runs the actual sync and can be called by all of the main workflows (i.e. called by the Solution Instance Trigger workflow, the Scheduled Trigger workflow, the Webhook Trigger workflow)