1. Feature Overview
When setting up your flows, you may need to use credentials or tokens that remain consistent across flows. UDS supports this through Global Variables, which can be defined within an App. Global Variables provide a secure space to store and reuse values like authentication tokens, API keys, or passwords across multiple flows and flow actions within the same application.
For sensitive information, such as credenitals, you can mark the variable as a password type, ensuring it is securely stored and encrypted. These values remain hidden even in logs, offering enhanced security.
By using Global Variables, you simplify configuration, reduce redundancy, and centrally manage credentials and other reusable data across your flows.
If you’re new to UDS, see Getting Started with UDS.
Note:
- All variable are stored in a secure, masked format to ensure the highest level of security.
2. Prerequisites
- You must be an Administrator user, or access must be shared to you by an Admin user.
- The Universal Data Sync Connector is a paid feature. To enable it on your account, contact your account manager, or write to support@leadsquared.com.
- You must first create an App within UDS before you define global variables. For more information, see Create an App on UDS.
3. Global Variable Types
UDS supports different types of global variables, each serving a specific purpose:
System Variables
These are available by default and provide context-specific information related to your UDS environment or LeadSquared account. You don’t need to configure them manually.
Custom Variables
These are created by users to store values such as tokens, credentials, or any reusable data needed across flows.
4. System Variables
These are predefined variables related to LeadSquared and UDS. They can be directly used in flows to dynamically render their actual values during execution.
Here’s a description of the system varaibles:
Variable Display Name | Description | Variable Schema |
ORG_ID | Identifier for an organization ID | {{global_variable.ORG_ID}} |
LSQ_BASE_ENDPOINT | Base endpoint URL for LSQ (For example, if your account is in india region, it will have value https://api-in21.leadsquared.com) | {{global_variable.LSQ_BASE_ENDPOINT}} |
LSQ_ACCESS_KEY | Access key of System User of your Leadsquared Account . This data will be passed in encrypted format. Note: This is an internal user, you cannot locate this user inside Manage users list. | {{global_variable.LSQ_ACCESS_KEY}} |
LSQ_SECRET_KEY | Secret key of System User of your Leadsquared Account . This data will be passed in encrypted format. Note: This is an internal user, you cannot locate this user inside Manage users list. | {{global_variable.LSQ_SECRET_KEY}} |
APPLICATION_NAME | Name of your UDS Application where this variable is used. | {{global_variable.APPLICATION_NAME}} |
APPLICATION_ID | ID (unique identifier) of your UDS Application where this variable is used. | {{global_variable.APPLICATION_ID}} |
DATAFLOW_NAME | Name of the UDS flow where this variable is used. | {{global_variable.DATAFLOW_NAME}} |
DATAFLOW_ID | ID (unique identifier) of the UDS flow where this variable is used. | {{global_variable.DATAFLOW_ID}} |
WEBHOOK_URL | Webhook URL of the UDS flow where this variable is used. | {{global_variable.WEBHOOK_URL}} |
LEAD_ID | Unique identifier for a lead (prospect ID), available when the trigger inside UDS is set to ‘Automation/Webhook‘ and data is sent from Automation/webhook. | {{global_variable.LEAD_ID}} |
REQUEST_ID | Identifies the individual request pushed for execution. In the case of bulk or scheduled triggers—where multiple records are fetched or received for processing from the source—BATCH_REQUEST_ID represents the root-level identifier, while REQUEST_ID refers to each specific request within that batch being processed. | {{global_variable.REQUEST_ID}} |
BATCH_REQUEST_ID | Represents the root-level identifier for requests. In bulk or scheduled triggers—where multiple records are fetched or received for processing from the source—BATCH_REQUEST_ID identifies the overall batch, while REQUEST_ID refers to each specific request within that batch being processed. If your trigger receives the individual data to be processed then | {{global_variable.BATCH_REQUEST_ID}} |
REQUEST_CALLER_SRC | Represents the context of the UDS flow execution. Typically follows the format: connector-ulc-{{YourOrgID}}-{{Your UDS Application ID}}-{{Your UDS FlowID}}. Use this value when calling your APIs to retain contextual information in your API logs. | {{global_variable.REQUEST_CALLER_SRC}} |
5. Custom Global Variables
These are created by users to store values such as tokens, credentials, or any reusable data needed across flows.
Currently, UDS supports three ways to set the value of a Custom Variable:
- Custom – Manually enter the value you want to assign to the variable. Ideal for static tokens or fixed configuration values.
- Call an API- Configure a custom API call to dynamically fetch the value. This is useful when the variable value (e.g., token) changes periodically. You can also define how frequently the API should be called, especially for time-bound or expiring values.
- OAuth – Use a predefined list of supported applications to complete the OAuth flow. Once authenticated, UDS will automatically fetch and manage the token required to call the app’s APIs.
To add a custom variable –
- Navigate to the Global Variables section within your app and click the Add New button.
- Provide a Display Name for your variable. Supported characters: Uppercase letters (A–Z), lowercase letters (a–z), numbers (0–9), hyphen (-), underscore (_), and spaces.
- Choose the appropriate data type based on the kind of value you intend to store (e.g., Text, Number, Password).
- Optionally, add a short description to help identify the purpose of this variable.
- Choose how to set the value. UDS supports three methods for assigning the value of the variable:
- Custom: Manually enter a static value for the variable.
- Call an API: Refer to section 6.2
- OAuth: Refer to section 7
- Click Save.
6. How to Configure a Custom Global Variable of Type API
For example, let’s say we need to call an API to generate an authentication token to securely connect to a third-party application. The API requires a AccessKey and SecretKey parameters in the request, and returns the AuthToken in the response. We’ll create 3 variables –
- For Access_Key and Secret_Key, we’ll select the value of the variable as Custom and hard-code the values.
- For the Auth_Token, we’ll select the value of the variable as Call API, and configure the API to pass the AccessKey and SecretKey in the request and populate the AuthToken from the response.
Note:
- If you already have a cURL command, you can paste it to automatically populate the method, endpoint, headers, and body fields.
- Alternatively, you can manually define the API request by specifying the method, URL, headers, and request body.
- If your API requires input values—such as a client ID or other parameters—you can either hardcode the values or create supporting variables. These supporting variables can be assigned values by mapping them to existing global variables. This enables dynamic value passing and avoids hardcoding, making your configuration more secure and maintainable.
6.1 Call API Settings
After selecting Call API, configure the API. This involves 3 steps –
1. Input cURL Request –
- Click Edit Details and enter the API cURL request.
- Scroll down and click Save & Next.
2. Variables –
- The parameters are automatically populated based on your cURL request.
- Change the Type of the parameter if required.
- Under the Mapping column, map the parameters from the cURL request to the global variables you’ve created, or type the values in manually and press enter.
- Use the delete icon under the Actions column to remove unwanted parameters.
- Scroll down and click Save & Next.
3. API Configuration –
This section is auto-populated based on your cURL request. If required, you can make changes to the API configurations here –
- Edit the request method (Post, Get, etc.).
- On the top right section, click View Merge Fields. You’ll see the list of parameters and LeadSquared system global variables (e.g., LEAD_ID, ORG_ID, LSQ_SECRET_KEY, APPLICATION_ID, etc.). You can append these parameters to the API query string or the the request body.
- On the Headers tab, click Add New to add headers to the API request. Enter the required key-value pairs.
- Navigate to the Body tab and review the request body. If required, change the request format (e.g., Click the View Merge Fields link to copy and add additional parameters.
- Click Save & Close when you’re done.
6.2 Response Mapping For Success
Response Mapping for Success allows you to define the structure of your API’s success response, specify which key’s value from the response should be stored in the defined variable, and set how long this value should be cached to avoid multiple calls (if required in case of time bound token expiry).
6.2.1 Data Key Selection
Here you need to provide a sample response for configured API so the system understands the response structure. and then specify the exact key or path in the response that holds the value you want to extract and store in the global variable.
6.2.2 Success Criteria
This section allows you to customize what success means for your API requests. By default, any response with a 2xx
status code is treated as successful.
While this works for most standard scenarios, it may not be sufficient for all APIs. In some cases, an API might return a 4xx
or 5xx
status code even when the operation was actually successful from your workflow’s perspective. Alternatively, the response body may contain specific keywords or flags that indicate success, regardless of the status code.
With custom success conditions, you can define logic that evaluates both the status code and content of the response. This gives you complete control over how success is interpreted within your workflow.
Example:
Lets say your API returns following response body with response status code as 400
{
"status": 400,
"message": "Previous token is not expired",
"AuthToken": "xxxxxxxxxxxxxxxxxx"
}
Here’s how you can configure success response mapping –
6.3 Response Mapping For Errors
This section allows you to set the definition of error for your workflow and retry logic.
By default, any response outside the 2xx
status code range is considered an error.
While this works for most standard scenarios, some APIs may return a 2xx
status even when the operation has actually failed. In such cases, relying solely on status codes may not accurately reflect the true outcome.
Custom Error Conditions let you define logic that evaluates both the response status code and the content. This gives you complete control over how errors are identified within your workflow.
2xx
range. This ensures your retry behavior remains accurate and intentional.Example:
Lets say your API returns following response body with response status code as 200
{
"status": 200,
"message": "error"
}
The Call API configuration is now complete. The hard coded Access_Key and Secret_Key variables will now be passed in the third-party API request body, and the Auth_Token variable will be populated with the value from the API response.
7. How to Create Custom OAuth Variables
OAuth allows you to securely connect LeadSquared with external applications using your login credentials.
Note: At present, the providers listed below are supported:
- Zoho Desk
- Zoho CRM
- Google Contacts
If your preferred app isn’t listed in your account, you can request it by emailing support@leadsquared.com.
Steps to Configure OAuth
- Create a custom OAuth variable.
- In OAuth Settings, ensure the desired provider is enabled.
- Under the Connect Provider tab, select the provider from the dropdown.
- Grant LeadSquared the necessary read/write permissions.
- Click Sign In to securely authenticate with the provider.
- Once signed in, click Save to complete the setup.
8. FAQs
1. How does Auto-retry work?
If retry is configured, the system will make up to 3 attempts at an interval of 10 seconds until a successful response is received.
2. If I have added multiple conditions in success/response mapping, how will they be evaluated?
When multiple success or error conditions are added, they are evaluated using an OR logic. This means if any one of the conditions is met, the request will be marked as success or error, accordingly.
9. Next Steps
After defining the global variables, let’s Create a Flow.
Any Questions?
Did you find this article helpful? Please let us know any feedback you may have in the comments section below. We’d love to hear from you and help you out!