---
sourceDocument: Brazil Service Exchange
sourceDocumentLink: https://www.servicenow.com/docs/r/service-exchange

 Release :

    - brazil

ft:locale :

    - en-US

ft:publication_title :

    - Brazil Service Exchange

ft:clusterId :

    - sebrdg

bundleId :

    - sebrdg

workflow :

    - Customer and Industry


---

# Remote task definition

# Remote task definition {#ariaid-title1}

Release version: Brazil  
Updated September 21, 2026  
![](https://www.servicenow.com/docs/portal-asset/ico-clock) 1 minute to read  
A remote task definition (RTD) is the provider-side configuration that determines how tasks synchronize between a provider and consumer instance in Service Exchange. It defines the linked tables, the field mappings, and the
consumer entitlements.
An RTD doesn't represent an actual piece of work. It is the reusable blueprint that a remote task is created from whenever an incident, case, or service request needs to synchronize between the provider and consumer instances.

## What an RTD defines {#se-rtd-overview__section_ecv_nzp_qkc}

An RTD links one provider table and one consumer table, for example Case to Incident, and specifies the following information.{#se-rtd-overview__se-rtd-overview-defines-1}

* Inbound fields: data the provider receives from the consumer when a remote task is created or updated.
* Outbound fields: data the provider sends to the consumer.
* Virtual fields: fields that exist on one side's table but not the other. Since there's no matching field to map to, the value comes from a transform instead of a direct mapping.
* Consumer criteria: which consumers are entitled to use this RTD.

{#se-rtd-overview__ul_nkb_ymq_qkc}

When the RTD is published, the system automatically generates remote task variables from the inbound fields. These variables render on the actual remote task form.{#se-rtd-overview__se-rtd-overview-defines-2}

## Lifecycle {#se-rtd-overview__se-rtd-overview-lifecycle}

A remote task definition moves through Draft, Published, Inactive, Archived, and Retired states. Publishing entitles the RTD to matching consumers. You can revise a published RTD through a configuration revision. Checking out an RTD
creates a new Draft version. When you publish that version, the system moves the previous version to Inactive rather than removing it. This ensures existing consumers continue working until they explicitly upgrade.  
The following table lists the tasks for creating an RTD and for creating a remote task from a RTD.{#se-rtd-overview__table_zqx_w4q_qkc__entry__3}

| Link | Created in | Description |
|-|-|-|
| [Create a remote task definition in Service Exchange for Providers](https://www.servicenow.com/docs/73pyZam88ExAohG8YbDeRQ "As a provider, create remote task definitions (RTD) that trigger the assignment of a remote task.") | Service Exchange | An administrator selects the provider and consumer tables directly, then maps each inbound and outbound field manually. |
|   | Service Exchange | An administrator describes the tables to ServiceNow Otto, which generates the field mappings automatically for review before publishing. |
| [Create a remote task using Workflow Studio in Service Exchange for Providers](https://www.servicenow.com/docs/1ZFc2OpQQ~nBFI_kSIPQTg "As a provider, proactively create remote tasks for your customers by using Workflow Studio.") | Workflow Studio | A flow, built once, creates a remote task automatically from a published RTD whenever its trigger condition is met. |
[ ]

{#se-rtd-overview__table_zqx_w4q_qkc}