SmartConnect tasks by default will always run when the integration reaches the configured step, for example send an email on integration failure. There are some real-world scenarios where we only want tasks to run when certain conditions are met. Below are some examples of custom conditions for running tasks.

If no data returned from source, don’t run child integrations

Scenario: I have a parent integration that imports a sales header document and a child that imports lines. If the query for sales headers is blank in the source, I don’t want to run the sales lines child integration.

A new feature was recently added to SmartConnect, making this option very simple to configure.

1. Open the Options tab of an integration.
2. Set the option for If No Data Returned From Data Source to Don’t run any tasks.

If error message contains string, don’t send email

Scenario: Users are receiving emails every time an integration fails. They don’t want to see errors that contain a specific error message.

1. Create a new task named CONDITIONAL_EMAIL_CHECK
2. Set the Type to Run Script
3. Set the Stage to run on the same stage as your Email Task
4. Set the On Failure option to Cancel processing.
5. Enter a script like the following to return false when you don’t want to send the email and to return true when you do want an email sent.

If Global Variable is empty, don’t run child integration

Scenario: I have a global variable with a list of email addresses for recently created contacts that I want to add to a marketing list. If the list of email addresses is blank, then I don’t want to run the child integration to add emails to a marketing list.

1. Create a new task named CONDITIONAL_RUN_MAP_CHECK
2. Set the Type to Run Script
3. Set the Stage to run on the same stage as your Run Integration Task
4. Set the On Failure option to Cancel processing.
5. Enter a script like the following to check the value of the global variable and return true if the global variable contains a value, and return false if the global variable is empty.

Make sure the script task is always above the task you want to control. Use the arrows in the top left to reorganize the tasks.

Conclusion

These are simple examples, but the logic in your script tasks can be as complex as required, as long as they return true or false to notify the task to cancel processing.

Another useful scenario for Script tasks before other tasks is to clean the value in global variables before passing the data to another task. A common example is to edit the GlobalRunErrors variable to return a custom formatting or manipulate common error messages into custom messages to assist end-users in resolving a particular error.