To create a new template, select Design New Template from your Cyclr dashboard. You can then select the Settings button from the top bar on the template builder page. There are several tabs with different options to allow you to configure how that specific Template works.
Settings Tab #
On Step Error #
You can determine what happens when an integration encounters an error when making an API call.
An error in this context is defined as Cyclr making an API call but not receiving a 200 HTTP Status Code from the external system. Any 4xx or 5xx HTTP Status Codes indicate an error, e.g. a 404 or a 500.
| Option | Description |
|---|---|
| Ignore (default) | No special action is performed if the Cycle encounters any errors and Transactions with errors will continue on through the Cycle. |
| Retry after a wait | If the Cycle encounters an error, failed calls will be retried after a selectable number of attempts. You can define the number of “Max retries” Cyclr will perform. Each retry attempt has an increasing delay: Retry 1: occurs a minimum of 5 minutes after the initial call that failed. Retry 2: occurs a minimum of 35 minutes after Retry 1. Retry 3: occurs a minimum of 1 hour and 35 minutes after Retry 2. Retry 4: occurs a minimum of 4 hours 35 minutes from Retry 3 Retry 5: occurs a minimum of 10 hours and 35 minutes from Retry 4. With all 5 Retries selected, Cyclr will make a total of 6 calls (1 initial call and 5 Retries) over a minimum period of 17 hours and 25 minutes before stopping the related Transaction and logging a Step Error. Note: Cyclr will only perform retries when making a single call as part of a Transaction, not in situations where multiple calls are made, such as Outbound/Inbound Paging calls or iterating over a list of items where each is a separate call. |
| Stop the integration | If the Cycle encounters any errors, the entire Cycle will be stopped and no further runs will be made until it’s manually restarted. |
| Stop the transaction | If the Cycle encounters any errors, only the specific Transaction that encountered the error is stopped, all other Transactions will continue and further runs will be made as scheduled. |
Log Step Requests #
Log Step Requests is the default setting. When active, this setting means that your integration logs both the requests and the responses in the step data.
Collection Splitting #
| Setting | Behavior |
|---|---|
| First (Trigger) Step | Splits a collection of data on the first step in a cycle. |
| All Steps | Splits collections of data on all steps. |
| None | Doesn’t perform any collection splitting. |
Collection Splitting can also be overridden on individual Steps within their Step Setup popups.
For more information, see the documentation page on Collection Splitting.
Variables #
You can define variables in the Variables tab and then use them in your integration. Once you define a variable, it’s available for you to map to any fields of the Steps in your integration.
Variables and the User Configurable flag #
When a Variable is set in a Template as “User Configurable”, changing its value in a new Template Release and pushing that live to upgrade existing Cycles won’t change the value of the Variable in the Cycles.
It will change and update Variables not set as User Configurable as they are considered part of the Template.
Data Retention #
In the Data Retention tab, you can use the two toggles to set a specific period of time to retain data on a step. You can set different time periods for data retention for Successful Transactions and Errored Transactions.
If you set a specific time in the cycle settings, this value overrides any global settings you have for your Cyclr application. Cyclr displays the current default value under the toggles.
For more information, see the Cyclr documentation on Data retention.
Audit Log #
The Audit Log tab displays a log of key events that relate to the template integration. Each event records a Username, Comment, and Timestamp in relation to the event.
Connector Installation #
The Connector Installation tab displays a list of all of the Connectors used by the Template.
When you install the Template into an Account, the settings on this tab are used to determine whether existing Connectors of the same type found in the account – if present – are used, or if new Connectors are always installed.
Depending on your use-case, you can decide on the appropriate behaviour.
Each Connector has a separate dropdown where you can select either:
- Existing Installation – if an existing Connector of the correct type exists, it will be used. If not, a new instance of the Connector will be installed and need to be setup or authenticated.
- Fresh Installation – a new instance of that Connector will always be created when the Template is installed, which will therefore need to be setup or authenticated.
The default setting for each Connector is to use existing instances if present.
