All Products
Search
Document Center

Dataphin:Objects to be published

Last Updated:Jan 13, 2026

After a deployment package from a source environment is imported into a target environment, the data objects it contains are displayed on the deployment package overview page based on the import rules. You can manage or publish these objects from the overview page as needed.

Prerequisites

A deployment package file from the source environment has been imported into the target environment. For more information, see Import a deployment package.

Notes

  • To ensure data security in the production environment and prevent data failures caused by incorrect object dependencies, the system enters a maintenance state during object publishing. This prevents issues that can be caused by concurrent operations. After the publishing is complete, a system administrator or super administrator must manually stop the maintenance state. Other users can use the system normally only after the maintenance state is stopped.

  • If an object in the deployment package has the same version as the corresponding object in the current environment, it does not need to be published. However, this object is still counted in the total number of objects on the overview page.

Note

Dataphin V3.11 supports exporting historical objects created before Dataphin V3.9 and publishing them to other tenants.

Permissions

Only users with the cross-tenant publishing user role can access and manage objects that are waiting to be published.

Access the deployment package overview

  1. Log on to Dataphin with a cross-tenant publishing user account.

  2. On the Dataphin homepage, from the top menu bar, select Management Center > Cross-tenant Publish.

  3. In the navigation pane on the left, choose Migration > Import Deployment Package.

  4. In the Actions column of the target deployment package, click the image publish icon.

Deployment package overview

The deployment package overview page shows a comparison between the imported package and the current environment. It also shows the number of changed objects and statistics about their publishing status: To be published, Publishing, Succeeded, Failed, or Succeeded with risks. On this page, you can publish and manage objects of various types and statuses. The objects are grouped by functional module: Global, Data Architecture, Development, Tag Architecture, Tag, Data Standard, Data Quality, and Data Security.

Note

The deployment package overview page shows only the objects that need to be published. Objects in the package that have the same version as their counterparts in the current environment are ignored.

image

Area

Description

Operations area

Supports the following operations: Modify Publish Settings, Reparse, One-click Publish, and Refresh.

  • Modify Publish Settings: Publishing settings are a prerequisite for publishing objects in a deployment package. If the settings change, click Modify Publish Settings to go to the import settings page and quickly update them.

  • Reparse: The system compares the objects in the deployment package with the objects in the current environment. If the versions match, the object does not need to be published. If the versions are different, or if the object is new or marked for deletion, its status is set to To be published. If the version of the corresponding object in the current environment has changed, reparsing might result in a different status for the object.

  • One-click Publish: The system publishes the objects sequentially. During the process, you can click Stop Publish.

    During a one-click publish, if no strong dependencies exist between objects, they are published in the order they appear on the page. The failure of an object in a previous stage does not interrupt the publishing process. For the recommended publishing order, see Recommended publishing order.

    When you stop the publishing process, the system only stops the functional modules that are not being published. It does not stop modules that are currently being published or roll back modules that are already complete. If you restart the process after stopping, the system will republish the failed objects and the objects that were waiting to be published.

    Note
    • Before you use one-click publish, you must complete the publish settings. Otherwise, the one-click publish cannot proceed.

    • During a one-click publish, if compute engines are included, the system uses the configuration from the source environment to publish them. If data sources are included, the system applies the replacement rules before publishing. If object information is insufficient, such as missing connection details, authentication details, or files, the publishing will fail.

    • To avoid potential data loss when compute engine information is the same in both tenants, first publish the compute engines and data sources. After that is complete, perform the one-click publish.

  • Refresh: Refreshes the list of objects to be published.

Publish Object List

The system divides objects into functional modules and displays a card for each module. The cards show the status and object information for the corresponding module.

  • Status: The system displays a status icon on each card to indicate the publishing status of the functional module.

    • image.svg: The module is waiting to be published.

    • image.svg: The module contains objects that failed to publish.

    • image.svg: The module is being published.

    • image.svg: All objects in the module were published successfully.

  • Object information: The total number of objects (excluding objects that do not need to be published) and the number of objects in each publishing status: To be published, Publishing, Succeeded, Succeeded with risks, and Failed.

  • View Details: If a functional module contains changed objects, click the image icon on its card to view the details.

Change types

When you import a deployment package file, the system automatically identifies and marks the change type for each object based on the following rules. The change types are Add, Update, and Delete.

  • Add: If an object in the imported package does not exist in the target environment, its change type is Add. When you publish this type of object, it will be added to the target environment.

  • Update: If an object in the imported package already exists in the target environment but has a different version, its change type is Update. When you publish this type of object, it will overwrite the corresponding object in the target environment.

  • Delete: If the imported package does not contain an object that exists in the target environment, its change type is Delete. When you publish this type of object, the corresponding object will be deleted from the target environment.

Permissions for publishing objects

After you import a deployment package file, the cross-tenant publishing user must also have the required publish permissions for the corresponding object types to publish the objects to a production or development environment. The required permissions are described below:

Object to publish

Subtype

Permissions required

Global

  • Statistic period

  • Global variable

  • Public calendar

  • Object property

  • Identification feature

Requires a cross-tenant publishing user with the super administrator or system administrator role.

Data block

Requires a cross-tenant publishing user with the super administrator or system administrator role, or a data block architect for the corresponding block.

Compute engine

Requires a cross-tenant publishing user who also has one of the following roles or permissions: super administrator, system administrator, data block architect for the block that is bound to the compute engine, or compute engine owner.

Project

Requires a cross-tenant publishing user who also has one of the following roles or permissions: super administrator, system administrator, data block architect for the block that is bound to the compute engine, or project owner.

Data source

Requires a cross-tenant publishing user with the data source administrator or data source owner role.

Data architecture

  • Business object

  • Business activity

  • Subject area

Requires a cross-tenant publishing user with the super administrator or system administrator role, or a data block architect for the corresponding block.

Development object

  • Integration Tasks

  • Modeling development

  • Metric development

  • File management

  • Compute Task

  • Offline physical table

Requires a cross-tenant publishing user with super administrator permissions. Alternatively, the user must be a cross-tenant publishing user and a member of the project that contains the object, and have submit permissions for Dev or Basic projects or publish permissions for Prod projects.

  • Tag architecture

  • Tag

  • Tag entity

  • Tag entity ID

  • Workbench object

Requires a cross-tenant publishing user with the super administrator or system administrator role.

Data standard

  • Lookup table folder

  • Data standard set folder

  • Public standard property

  • Standard template

  • Data standard set

  • Data standard

  • Mapping rule

  • Mapping relationship (asset granularity)

  • Lookup table

  • Root

Requires a cross-tenant publishing user with the super administrator or system administrator role.

Data quality

  • Quality rule template

  • Quality rule (object granularity)

Requires a cross-tenant publishing user with the super administrator or system administrator role.

Data security

  • Data categorization

  • Data classification

  • Identification result (table granularity)

  • Key

Requires a cross-tenant publishing user with the super administrator or system administrator role.

Recommended publishing order

Publish objects in the following order, which is based on their dependencies.

  1. Global (Compute engine -> Data source -> Statistic period -> Global variable -> Public calendar -> Object property -> Python third-party package -> Data block -> Project -> Identification feature)

  2. Data architecture (Subject area -> Business activity -> Business object)

  3. Data security (Key -> Data categorization -> Data classification -> Identification feature)

  4. Data standard (Lookup table folder -> Lookup table -> Root -> Data standard set folder -> Data standard set -> Public standard property -> Standard template)

  5. Data quality (Rule template)

  6. Standard (Data standard -> Mapping rule)

  7. Development (Offline physical table -> Node)

  8. Tag architecture (Tag entity -> Tag entity ID)

  9. Tag (Workbench object)

  10. Data quality (Quality rule)

  11. Data standard (Mapping relationship)

  12. Data security (Identification result)