Distribution of Application Templates

extreme Designer Administrator
This manual is in pilot operation.

(fusion_place >= 11.1)

This feature is limited to the extreme license.

The distribution of application templates is a feature that distributes and reflects the design objects of an application to another application.


This feature allows the design objects of one application to be distributed and reflected in a different application. Only design objects are distributed, and administrative objects are not distributed. Therefore, in the destination application, it is possible to register/set up its own administrative objects. One typical use of this feature is the construction of a standard management accounting system to be deployed across group companies.

The headquarters creates a common template application (source application), which is then distributed to each group company. Each group company registers its own unique accounts and departments in the distributed application (destination application) for use.

Using this feature, when design objects are added, changed, or deleted in the source application, those changes can be distributed to each destination application.

For example, in the department dimension of the source application, register the "Total" member as a template member (design object). In the destination application, each company can register its own departments under this member. The departments registered by each company are "user-defined members" (administrative objects).

When there are changes to design objects in the source application, such as adding dimensions or ledgers, or modifying/adding forms, the template (the entirety of design objects) of the source application can be exported and imported into the destination application to distribute the changes. In this case, user-defined members and data already registered in the destination application are generally retained as is.

Exporting and Importing Templates

To export the entirety of design objects, i.e., the template from the source application, use [Web-API] (or Requester). The request type for exporting is as follows:


The template data is in hexadecimal format, and its format is not public. To import template data into the destination application, use [Web-API] (or Requester) as well. The request type for importing is as follows:


Note that import operations may fail due to conflicts with other processes, such as dimension updates. In such cases, the destination application remains unchanged. Determine the presence of an error through the "operation result code" in the response body or the exit code of the Requester, and retry if necessary.

If the process fails, the operation result code will be FAILED, and the Requester’s exit code will be 8.


Avoiding Member Label Conflicts

Regarding template members in dimensions, the contents registered in the source application are distributed to the destination application. However, user-defined members are registered on the side of the destination application and are not distributed from the source application. Therefore, it is necessary to be mindful operationally to avoid conflicts between their labels. To support such operations, template member label constraints can be registered for each dimension.

Template member label constraints, being design objects, are distributed from the source application to the destination application.

Cases Where Data Is Deleted

Importing template data into the destination application may result in the deletion of data registered on the side of the destination application. For example, if a ledger definition exists in the destination application but not on the source side, it is natural for that ledger definition (a design object) to be deleted; consequently, the content data specified by that ledger definition will also be deleted. For cases like these, please see Cases Where Data Is Deleted/Changed.

Backing Up

Before executing the import operation of the application template, which will change/delete design objects in the destination application and cannot be undone, it is recommended to obtain a backup of the destination application.

The backup and import operations can be executed as a series of processes via Requester or [Web-API].
Using Administrator Privileges in the Destination Application

To avoid the risk of modifying design objects in the destination application, it is recommended to use Administrator privileges, which allow adding, changing, and deleting only administrative objects.

Cases Where Data Is Deleted/Changed

Below are cases where data registered on the side of the destination application may be deleted/changed due to the incorporation of template data.

Design Object Causing the Issue Cases Where Data Is Deleted/Changed


If the application types between the source and destination differ, the application type of the destination will be changed, and any administrative objects or operational data that cannot be held by the changed application will be deleted.

Period Table

If the structure of the period table differs between the source and destination, all ledger data will be deleted, and all scenarios for all years/periods will be closed. Additionally, all business processes will be deleted.

The structure of the period table includes the labels and hierarchical structure of relative periods, types and labels of views, and the correspondence between relative periods and hierarchies. The names of relative periods and views are not included.


If a scenario exists in the destination that is not in the source, or if the least period unit is changed, all ledger data for that scenario will be deleted.


If a dimension exists in the destination that is not in the source, the dimension in the destination will be deleted. User-defined members included in it will also be deleted.

Even if a dimension with the same label exists, if the dimension type or the dimension it borrows from is different, the dimension in the destination will be deleted, and a new dimension with the same label will be created.

If a Dimension Is Deleted

Any ledger or business process[1] using that dimension will also be deleted.

If there are account or note item dimension members that use that dimension as the "value list source dimension," their data type will change from "enumeration" to "none," and the "value list source dimension" specification will be cleared.

If a Dimension Is Updated

When reflecting template members from the source dimension in the destination dimension, if user-defined members with the same label exist, the label of those members will be changed to a dummy label (__ + sequence number).

If template members not present in the source dimension exist in the destination dimension, their "usage classification" will be set to "not used."

1. Not when a ledger is used in a form for a business process, but when that dimension is used as the responsibility splitter dimension in the submission route definition applied to that business process

Ledger Definition

All data for that ledger will be deleted in the following cases:

  • If a ledger definition exists in the destination that is not in the source

  • Even if it exists, if the dimension composition is different

  • If changing from a note ledger to a non-note ledger (or vice versa)

  • If a view ledger with the same label as a non-view ledger existing in the destination exists in the source

Access Permission Type

If an access permission type exists in the destination that is not in the source, the access permission type applied to the participant unit will become "No Access (System Defined)/#NO_ACCESS."

Translation Table

If a translation table exists in the destination that is not in the source, the translation table will be deleted, along with the translation rules registered in that table.

Submission Route Definition

If a submission route definition exists in the destination that is not in the source, the submission route definition will be deleted, along with the route details registered in that submission route definition.