When a team member leaves or is removed, their DataWorks entities — resources and functions — need a new owner to keep your pipelines running. DataWorks handles this automatically when a RAM user is deleted or removed from a workspace. For active members, you can trigger a transfer manually.
Transfers follow two rule types: a default transfer rule (always active, cannot be disabled) and an optional custom transfer rule that you configure at the workspace or tenant level. The custom rule takes priority; if its receiver is invalid, the default rule applies as a fallback.
Prerequisites
Before you begin, ensure that you have:
-
The tenant security administrator or tenant administrator role
For information about tenant-level permission management, see Manage permissions on global-level services.
How transfers work
The following diagram shows how DataWorks selects a receiver when a transfer is triggered:
DataWorks applies rules in this order:
-
Custom transfer rule — if configured, enabled, and the specified receiver is a valid workspace member, entities go to that receiver.
-
Default transfer rule — applies when no custom rule is configured, the custom rule is disabled, or the specified receiver is invalid (for example, removed from the workspace).
The default transfer rule is always enabled and cannot be disabled.
Transfer triggers
| Level | Mechanism | Trigger condition |
|---|---|---|
| Tenant | Automatic | RAM user is deleted |
| Workspace | Automatic | RAM user is deleted or removed from the workspace |
| Tenant or workspace | Manual | RAM user is not deleted and is still a workspace member |
Receiver fallback order
Tenant-level automatic transfer assigns the receiver in this order: primary responsible person → secondary responsible person → tertiary responsible person.
| Responsible person | Default |
|---|---|
| Primary | Blank by default — must be manually specified |
| Secondary | Tenant administrator (cannot be an Alibaba Cloud account) |
| Tertiary | Alibaba Cloud account |
Workspace-level automatic transfer assigns the receiver in this order: secondary responsible person → tertiary responsible person → fourth responsible person (when no primary is specified).
| Responsible person | Default |
|---|---|
| Primary | A specified person — no default |
| Secondary | Workspace administrator |
| Tertiary | Tenant administrator (Alibaba Cloud account cannot be tertiary) |
| Fourth | Alibaba Cloud account |
If multiple members qualify for the same fallback level, DataWorks selects the member who joined the workspace first.
MaxCompute access identity
If the receiver you specify is the access identity of a MaxCompute compute engine, that compute engine's access identity changes to the receiver after the transfer. For details, see Manage workspaces.
Go to the Entity transfer page
-
Log on to the DataWorks console. In the top navigation bar, select a region. In the left-side navigation pane, choose Data Governance > Security Center, then click Go to Security Center.
-
In the left-side navigation pane, choose Security policy > Entity transfer.
View transferable entities
On the Transfer configuration tab, the Entity Resources section lists every entity type that can be transferred, the module it belongs to, and a transfer description.
Transfer entities immediately
Use this approach when a RAM user has not been deleted and is still a workspace member.
-
On the Transfer configuration tab, click Immediate execution of referral.

-
In the Immediate execution of referral dialog box, set Original Responsible Person and Transfer To Target Responsible Person, then click Confirm referral. All tenant-level and workspace-level entities belonging to the original responsible person are transferred to the target.
If the target responsible person does not exist or is removed from the workspace, the transfer falls back to the default transfer rule.

Configure a tenant-level entity transfer rule
In the Tenant-level entity to target responsible person section of the Transfer configuration tab, configure the receivers for tenant-level automatic transfer. The system attempts transfer in order: primary → secondary → tertiary.
Click Revised in the Transfer to target responsible person column, then specify receivers in the Select the target responsible person dialog box:
-
Primary responsible person: blank by default. Specify a receiver manually.
-
Secondary responsible person: the tenant administrator by default. Cannot be an Alibaba Cloud account.
-
Tertiary responsible person: your Alibaba Cloud account by default.
Configure a workspace-level entity transfer rule
In the Workspace-level entity to target owner section, configure receivers for workspace-level automatic and manual transfers. If no primary responsible person is specified, the system falls back in order: secondary → tertiary → fourth responsible person.
Search for a workspace
Use the search box to find the workspace you want to configure.
Set an entity receiver
-
Find the workspace, then click Revised in the Transfer to target responsible person column.
-
In the Select the target responsible person dialog box, select a workspace member as the receiver.

Two rule types apply:
-
Default transfer rule: always enabled and cannot be disabled. Takes effect when no receiver is specified or the specified receiver is invalid.
Note: A receiver is considered invalid if they are removed from the workspace before the transfer occurs.
-
Custom workspace-level transfer rule: disabled by default. When enabled, entities are transferred to the receiver you specify. If that receiver is invalid, the system falls back to the default transfer rule.
-
-
In the Operation column, turn the switch on or off for the workspace:
-
On: entities go to the receiver you specified. If the receiver is invalid, the default transfer rule applies.
-
Off: entities go to the receiver defined by the default transfer rule.
-
View transfer logs
On the Transfer log tab of the Entity transfer page, review the Time of submission, Transfer method, and Transfer status for each transfer event. To download the full details for a transfer, click Download log in the Operation column.
Logs are retained for 183 days from the Time of submission. Logs older than 183 days cannot be downloaded.