- Getting started
- Notifications
- Licensing
- Troubleshooting
- Connector Builder
- Act! 365
- ActiveCampaign
- Active Directory - Preview
- Adobe Acrobat Sign
- Adobe PDF Services
- Amazon Bedrock
- Amazon Connect
- Amazon Polly
- Amazon SES
- Amazon Transcribe
- Amazon Web Services
- Anthropic Claude
- Asana
- AWeber
- Azure AI Document Intelligence
- Azure Maps
- BambooHR
- Box
- Brevo
- Calendly
- Campaign Monitor
- Cisco Webex Teams
- Citrix Hypervisor
- Citrix ShareFile
- Clearbit
- Confluence Cloud
- Constant Contact
- Coupa
- Customer.io
- Datadog
- Deputy
- Discord
- DocuSign
- Drip
- Dropbox
- Dropbox Business
- Egnyte
- Eventbrite
- Exchangerates
- Exchange Server - Preview
- Expensify
- Facebook
- Freshbooks
- Freshdesk
- Freshsales - Preview
- Freshservice
- GetResponse
- GitHub
- Gmail
- Google Cloud Platform
- Google Docs
- Google Drive
- Google Maps
- Google Sheets
- Google Speech-to-Text
- Google Text-to-Speech
- Google Tasks - Preview
- Google Vertex
- Google Vision - Preview
- Google Workspace - Preview
- GoToWebinar
- Greenhouse
- Hootsuite
- HTTP Webhook - Preview
- Hubspot CRM
- HubSpot Marketing
- HyperV - Preview
- iContact
- Insightly CRM
- Intercom
- Jira
- Keap
- Klaviyo
- LinkedIn
- Mail - Preview
- Mailchimp
- Mailgun
- Mailjet
- MailerLite
- Marketo
- Microsoft 365
- Microsoft Azure
- Microsoft Azure Active Directory
- Microsoft Azure OpenAI
- Microsoft Dynamics 365 CRM
- Microsoft OneDrive & Sharepoint
- Microsoft Outlook 365
- Microsoft Sentiment
- Microsoft Teams
- Microsoft Translator
- Microsoft Vision
- Miro
- NetIQ eDirectory
- Okta
- OpenAI
- Oracle Eloqua
- Oracle NetSuite
- PagerDuty
- PayPal
- PDFMonkey
- Pinecone
- Pipedrive
- QuickBooksOnline
- Quip
- Salesforce
- Salesforce Marketing Cloud
- SAP BAPI - Preview
- SAP Cloud for Customer
- SAP Concur
- SendGrid
- ServiceNow
- Shopify
- Slack
- SmartRecruiters
- Smartsheet
- Snowflake
- Stripe
- Sugar Enterprise
- Sugar Professional
- Sugar Sell
- Sugar Serve
- System Center - Preview
- TangoCard
- Todoist
- Trello
- Twilio
- UiPath GenAI Activities
- X (formerly Twitter)
- Xero
- watsonx.ai
- WhatsApp Business
- WooCommerce
- Workable
- Workday
- Workday REST - Preview
- VMware ESXi vSphere
- YouTube
- Zendesk
- Zoho Campaigns
- Zoho Desk
- Zoho Mail
- Zoom
- ZoomInfo
Creating a trigger
You can create a trigger as part of a custom-built connector. You can use custom connector triggers to automatically start automations or processes based on provider events.
Connector Builder triggers use resource polling to detect provider changes. Resource polling involves calling an API resource on a regular interval to detect when new events are returned.
Once a custom connector is published and the trigger is used in a published automation, the defined URL is used as the polling resource to pull back events and start an automation flow.
The trigger’s polling URL must include query parameters to filter the provider’s results.
Polling occurs at a scheduled interval (every 5, 10, 15 minutes, etc.). Therefore, one of the provider's query parameters must be a date for filtering results. This way, the polling engine can populate the query parameter value to only include events that occurred since the last polling time.
-
You can create one trigger per resource. If more than one use case is needed, use a more general polling URL and set up response filter fields that can meet multiple use cases.
-
Provider APIs must allow date-based query parameter filtering. If no date-based query parameters are available from the provider, it should not be used as a trigger.
GET
endpoint
that returns a list of objects. Additionally, the endpoint must allow you to query
the resource based on a date parameter.
Example of a valid resource
since
query parameter that filters the results by all activities with
an update_time
date greater than the since
date provided as a value to the query
parameter. You can use the since
parameter as
part of the polling URL to detect any updates to Pipedrive activities. The UiPath
polling engine automatically populates this date field to capture events.
Connector Builder triggers use resources that are already available on the connector as the polling URL. When creating a new trigger, there must be an existing resource on the connector side for the trigger to be associated with.
Triggers use the resource's configuration, so it is important that the existing resource already has:
-
Query parameters: triggers can import existing query parameters, so the resource should already have some parameters configured before creating the trigger.
-
Response fields: triggers output the response object of the associated resource, as well as allow for activity configuration based on these fields. It's necessary to generate the response fields for the resource by successfully calling the endpoint.
To create a trigger in Connector Builder, take the following steps:
- First, make sure you meet the prerequisites.
- In Integration Service, open Connector Builder, then select your custom connector.
- Select the More options menu next to Triggers.
- Select Add trigger.
The Create event pop-up window is displayed. Here you can select which type of event to create. Currently, Polling is the only available option.
- Select the event type.
- Add a name for your trigger.
- Select the resource used for detecting these events.
- Select Create to start the process of configuring your trigger.
The process of creating a trigger consists of three steps:
- Configure request.
- Configure response.
- Configure trigger filters.
These steps correspond to the process of polling a resource URL and working with the response.
Configure request
First, you configure how the polling URL is set up, and how the trigger is displayed in Studio when used in an automation.
The preview layout represents how the trigger is displayed in Studio. You can configure the parameters and response fields to change what fields you see and use in Studio when setting up the trigger for an automation.
Polling URL
The polling URL is displayed at the top of the configuration page. This is the URL used to make requests to the provider to detect new events.
This URL must be configured in a way that filters for events of interest. The polling URL uses a date parameter to filter for new events since the last polling request. It's mandatory to include a date parameter that the polling engine can populate.
Import parameters
Triggers can import resource parameters to use in the polling URL.
If a parameter isn't available in the resource, navigate to the resource and add it, then return to the trigger configuration window to import it.
- Select Import parameters to view the list of available parameters for a specific resource.
- Select the parameter you want to use in the polling URL.
- Once a parameter is added, it's included in the URL preview at the top of the page.
You can mark imported parameters as Required, so that they show up on the trigger canvas. This means you are required to enter a value for the query parameter when using the trigger in an automation.
DateTime
format. DateTime
formats can be found for a parameter with a String
or Integer
provider data type.
Test trigger
Use the Test trigger option to make sure that the expected results are being returned.
When you select Test trigger, the Try the request window is displayed, showing:
- Look-back period: this field defines what date should be inserted into the date-based query parameters and replicates the behavior of our polling engine, which automatically fills in this value based on the date of the last polling request.
- The query parameters specified as required.
Select Try request to open the Events Debug panel and see the request trace with a step-by-step breakdown of the request process. The number of results returned is also displayed.
Configure response
At this step, you specify which response field corresponds to the Primary key, or the trigger's output.
- Use the drop-down list under Primary key to select a field.
- The selected field is added to the trigger preview, under Output. You can use this output in later steps of your workflow.
Configure trigger filters
Once you configure the request and response, you can further configure the trigger using filters.
You configure event filtering by setting specific values for response fields. These values are specified during the automation setup (in Studio), but the trigger designer also allows you to configure what fields are displayed for filtering.
Hydration
GETBYID
endpoint. This process is known as hydration.
GETBYID
resource before using it as a hydration resource for a trigger.
Filters
The trigger configuration process offers three options for displaying fields used for filtering. These fields are pulled from the resource response fields of the polling resource or the hydration resource. These options are available under the Show as column of the Filter parameters table:
-
Hidden: the field is hidden from the canvas and is not available in Filter builder. If all fields are marked as Hidden, then the Filter builder is also hidden.
-
Optional: at design time, the field is displayed as an option in the Filter builder.
-
Required: at design time, the field is displayed directly on the trigger canvas and requires user input. Only events with a response field value matching the provided value result in an automation event.