'Trigger External API' Actions

Details around how to configure actions to trigger external APIs, and how they will display in Work Manager for operational users.

Similar to other action archetypes, 'Trigger External API' actions can be used in Case processes, and are used for when you need to automatically call out to another system, passing data to it and potentially getting the external system to pass updated custom data back into Enate.

For information on how to configure 'Trigger External API' Actions check out this Builder section.

Sometimes there can be a delay when waiting for the external system to respond. When that happens, i.e. when the ‘Trigger External API’ Action is waiting for information to come back from an external system, the Action info card will display in Work Manager as being in a state of 'Waiting'.

When the external system ultimately responds to Enate with the data update, it will be with a marker to say whether it has been successful OR unsuccessful:

Response with Successful Completion

If the system is responding to say it has been successful, the Action will automatically move to a state of 'Closed', with a Resolution Method of 'Done Successfully'.

Response with Unsuccessful Completion

If the system is responding to say it has been unsuccessful, the Action move into a state of 'To Do', with a reason of 'Updated by Integration'. The external API can also respond with additional information regarding why it was unsuccessful. This information will display in the Info card of the Action in the 'Rejected Reason' section.

If the Action isn't successful because it did not complete within the time set for it (configured in Builder), then it will moved to a state of 'To Do' with a reason of 'Timeout' and it will allocate to a Queue / human user based on the configured allocation rules.

Such unsuccessful Actions will now effectively behave as a standard manual action.

Please note that the Case owner will NOT be notified in these situations.

Automatic Retries

If the Action is not able to connect to the external system, it will automatically retry connecting for a certain number of times, depending on how your system has been configured in Builder (see here for more information). You will also be shown an error message bar on the Action showing:

• when the error occurred

• when the system will retry establishing a connection automatically

• how many times the system has automatically retried establishing a connection, and

• how many times the system will automatically retry establishing a connection.

You are able to manually retry establishing a connection from here too, by clicking the 'Retry' link in the error message.

Please note that when you do a manual retry, this will be counted as an attempted retry and will therefore be included in the number showing how many times the system has 'automatically' retried establishing a connection.

If the Action fails to establish a connection following the automatic retries (e.g. if the retry setting is set to 5 and the system fails to establish a connection following 5 automatic retries), it will move to a state of 'Closed' with a resolution method of 'Not Done Successfully'.

In this circumstance of the Action failing to establish connection with the external system, this will escalate to the Case Owner, highlighting in the Action section of the Case screen that this Action was Closed - Not Done Successfully.

When the Action receives the required information, it will close automatically.

Adjusting the retry settings in Builder during / after retries have begun

If the automatic retry setting in Builder is changed after the system has automatically retried establishing a connection with an external system, the following will occur:

If, for example, the retry setting was originally set to 5 and the system automatically retried establishing a connection 5 times but failed, the Action will have moved to a state of Closed with an error message showing a retry count of 5/5.

If the retry setting then gets subsequently increased to anything above 5, for example 7, the error message will display a retry count of 5/7, but the system will NOT automatically retry establishing a connection for a 6th and 7th time as the Action is already closed.

However, if the Action had not yet moved to a state of Closed because it had not yet reached the maximum number of automatic retries (e.g. it had only retried 4 times out of the 5), then increasing the retry setting to 7 means that the Action will automatically retry establishing connecting until the count has reached 7.

Conversely, if you reduce the retry setting after retries have started, e.g. you're on retry 4 of 10 but then reduce the max down to 4, the system will still display 4 of 10 but will in fact be closed.