Before creating the Workflow, we will need to generate a unique set of API keys to use later. From the Dashboard, navigate to Account->Settings and click on the API Keys header. If necessary, generate an unused pair of API keys via the + Add API Key button. Copy and paste these values into a private document, or otherwise store them for use later in the process.

From Account -> Workflow Automations on the Dashboard, click the blue button to + Add Workflow.

Name the Workflow something descriptive.

The first filtering step of any Workflow is the Trigger. We want our Trigger object to be a call, and as a Trigger action we choose ended. This combination will make it such that our automation will trigger in response to a call ending.

Our goal for this example also requires us to set some additional Conditions. The automation should not be triggered after every call ended. We firstly don't want to include calls without any talking time, as these would constitute dropped calls. Set this filter by making a Condition with a dynamic value. Click into the Property box. Then, from within the Useful Data for your Workflows section on the right, click talking_time to populate the box with the corresponding dynamic value. The resulting notation should match the picture below. As an Operand, choose is greater than, and as a Value, enter 10 in order to compensate for connection lag which may take place.

Another Condition should be added to filter for outbound calls only. +Add condition. Populate the Property box as in the previous condition, this time with the dynamic value for direction. As an Operand, choose is equal to, which will search for an exact character match. Type outgoing in all lowercase as the Value. If no other conditions need to be added, we can Confirm and continue.

There are three Action types to choose from. For the purposes of this example, we will be sending information back through the CloudTalk api. This requires an API request Action.

The API request Action is designed for flexibility of use, and therefore will require users to refer to additional documentation and resources in order to properly format headers and values. Since this example intends to make an API request to the CloudTalk api, we can refer to the CloudTalk API Reference for proper formatting. We are first expected to enter an Endpoint. To break things down, the necessary endpoint is going to involve some reference to the web address or token (https://my.cloudtalk.io/api), some reference to the aspect of the address we wish to manipulate (contacts), a reference to the particular contact in question (the contact id), some reference to what function we want to do for that contact (addTags), and finally a format type (.json). Following the API docs linked above, the format of our Endpoint will look like:

https://my.cloudtalk.io/api/contacts/addTags/{contactId}.json

As a Method, we choose PUT, asking the system to please put new information into the database if it does not yet exist. Notice also that in the picture, contactId is highlighted because this needs to be changed to a dynamic value which will allow the API to reference the actual ID for a given contact.

The dynamic value reference to insert in place of {contactId} looks like:

{{ event.properties.contacts[0].id }}

Most API calls require some form of authorization. This is where the API Keys retrieved from our Settings page will come in. Due to the creative way in which we are making a request back through the CloudTalk API itself, we will need to open a separate tab and elicit the help of an API platform such as Workato, SAP Integration, or AWS to construct the properly encoded format for our authorization header. For the sake of example, below is an image of what combining the Access Key ID and Access Key Secret might look like, via the Postman interface. The two keys will be entered as basic authorization values where the output will be a formatted header with a Key and an encrypted string Value.

Once we have obtained a Key:Value pair in proper format, we will enter these sequences into the aptly named boxes under Headers on our CloudTalk API request.

Within the Values section of the request, we can set the name of the tag we wish to be added when the automation is triggered. As a Key, enter tags.0 to reference the tags list. Enter the desired tag name in the Value box.

If there are no additional headers or values to be added, we can check over our API request Action and make sure all the field entries are the correct format. Then, Confirm and continue.

When we have saved the automation and set it to Active, it can start running. In cases where conditions are met, our tag outbound_lead will be automatically added to contact profiles that don't already have this tag.