Asset Actions

Users can interact with governed assets in Anjana Data Platform to update their metadata, request data access, o create new objects and relationships.
The availability of each action always depends on three factors:

1. Object type (dataset, process, business term, relationship, etc.).

2. Object status (draft, pending, approved, deprecated, expired, etc.).

3. User role permissions in the corresponding organizational unit.

Main lifecycle actions

Edit

Editing an asset means modifying its metadata, i.e., changing values in its attributes. For a dataset, it also includes the option to add or adjust its dataset fields.

An asset can only be edited if it is in one of the following states:

• Imported

• Draft

• Rejected

• Approved, provided there is no more recent draft or pending version. To check this, the header provides version indicators. See the Cabecera section within this guide.

• Deprecated, if it has no more recent approved, draft, pending or deprecated versions

• Expired, if it has no more recent approved/draft/pending/deprecated/expired versions

When the object is editable, the Save button appears in the header (initially disabled).
Editing is done directly on the form fields by clicking on the corresponding attribute.

Save

The Save action persists the changes made to the asset form. This operation:

• records the change in audit, and

• generates a snapshot of the object.

Save behavior by status:

• If the asset was in imported or rejected status, saving changes the status to draft with the changes applied.

• If the asset was in approved, deprecated or expired status, saving generates a new version in draft status, a copy of the original version with the changes applied. The approved, deprecated or expired version is maintained.

• If the asset was already in draft status, changes are applied to that same version without a status change.

Validations before saving:
When saving, Anjana Data Platform verifies that the configured validations are met (required attributes, value formats, specific rules, etc.).
If they are not met, the user is notified and the save is not completed until the errors are corrected. Only after a valid save is the Submit action enabled.

Unsaved changes:
If the user changes tab or leaves the detail view without saving, Anjana Data Platform displays a warning to confirm whether to persist the changes. If not saved, they are lost.

Large datasets:
In approved datasets with a large number of fields, saving may take several seconds. To avoid unnecessary waiting, Anjana Data Platform automatically redirects the user to the Search Portal showing an in-progress notice.

Submit

Enviar initiates the validation process for changes in a governance flow (workflow). Depending on the environment configuration, this action can:

• launch a validation workflow, changing the object to Pending status, or

• apply an automatic validation, leaving the object directly in Approved status.

In both cases:

• the process is audited,

• snapshots are saved for each workflow milestone (start, approvals/rejections, end).

The Submit button is only available from the Attributes view and is enabled when:

• there are correctly saved changes, or

• the object already meets all requirements since its creation.

Modificación Vs versionado 

Anjana Data Platform allows, for native entities with versioning, configuring attributes that, when modified, generate:

• a new version (based on versioning rules), or

• a modification on the current version,

Key rules:

• Versioning only applies to native entities.

• Non-native entities and relationships are never versioned: they are always modified.

If attributes are edited according to the versioning rules on an approved version, Anjana Data Platform informs the user that a new version will be created. At that point it can request:

• confirmation of the operation, and

• expiration date of the previous version (if not already defined), which will become deprecated.

If the object was deprecated or expired, any edit generates a new version and the user is informed that the versioning is due to the status change.

If the versioning object is a dataset with a large number of dataset fields, it may take a while to be sent for validation. To avoid unnecessary waiting, Anjana Data Platform redirects the user to the portal with a notice that the action will take time to complete.

Workflow launch vs. automatic validation

Exception rules can be configured for workflow launches, meaning that for certain attributes, changes are automatically validated without a workflow if performed by certain roles.

Thus:

• If the user edits only attributes covered by auto-approval rules, submission is approved directly.

• If other attributes outside those rules are edited, or the user lacks an auto-approval role, a workflow is always launched.

For example, if the Data Owner modifies the description of a business term, being the highest authority, the change is automatically approved without launching a validation flow.

Actions menu

The actions menu is accessible from different areas of the platform and displays additional operational actions:

• the three-dot ("…") button in the object header, or

• the same button available alongside Portal search results,

The most common possible actions are described below (the applicability detail by object type is documented in Functional Configuration):

Some actions require validation. After confirming an action, Anjana Data Platform evaluates which role assigned to the user can execute it according to their permissions:

• If the user has a single role with permissions, the corresponding workflow is automatically launched.

• If the user has multiple roles with permissions, they will be asked to select which one to use.

• If the user has no role with permissions, a permissions warning will be displayed.

Description of specific actions

The main actions of the contextual menu are consolidated below:

Activate

Changes the status of a non-native entity or relationship from Disabled → Approved, going through validation in accordance with the established workflow. The steps are:

1. El usuario selecciona la opción de Activate

2. the user receives a message to confirm the action

3. the established activation flow is launched to request validation from the participants

4. if the workflow is approved, the object moves to Approved status, otherwise it remains as Disabled

Direct adherence

The direct adherence action allows requesting access to data contained in a DSA without needing to add it to the cart first. This option streamlines the request when the user already knows they want to adhere to a specific agreement.

Request process

1. Reading/downloading the contract
   When initiating adherence, the form displays the acceptance checkbox and the reason field disabled.
   These elements are enabled only when the user:

   • downloads the contract, or

   • accesses the associated URL to review it.

2. Acceptance and reason
   Once the contract has been read/downloaded, the user can:

   • mark acceptance of the agreement, and

   • complete the reason for the request (if applicable).
     Doing so enables the confirmation button.

3. Submission for validation
   After confirming the request, Anjana Data launches a validation workflow for the DSA owners to approve or reject the adherence.

4. Result
   If adherence is approved, the user becomes adherent to the DSA, obtaining the corresponding access to the data defined in the agreement.

Add to cart

To request data access or information, the user must first add the corresponding assets to the cart.

The full operation of the cart and the detail of the request process is described in the Shopping Cart section of this User Guide.

When the user adds an object to the cart, the platform:

1. displays a confirmation message indicating that the action was completed successfully, and

2. adds the object to the cart panel, where it is available for subsequent management.

Add to workspace

This action allows adding an asset to the user's personal workspace to work with it later from that space. The workspace serves as a working area where relevant objects can be grouped and individual or bulk operations can be performed on them (metadata downloads, bulk edits or submissions for validation).

When the user adds an object to the workspace:

• the platform confirms the operation with a success message, and

• the asset becomes available in the user's workspace.

If many objects are added simultaneously, Anjana Data will display a progress indicator until the operation is complete.

For more information about workspace management and its features, see the Workspace section of this User Guide.

Add dataset field

This action allows creating new fields (dataset fields) within a dataset in a guided and quick way. It is available for datasets in the following states:

• Imported

• Draft

• Approved

• Rejected

• Deprecated, as long as no more recent version of the dataset exists.

When "Add dataset field" is selected, Anjana Data Platform:

1. automatically redirects to the Structure tab of the dataset, and

2. opens the creation form for the user to enter the information for the new field.

Once confirmed, the new dataset field is incorporated into the dataset.

Delete object

The Delete action permanently removes an object from the Anjana Data Platform Portal. In the case of a DSA or entities contained in a DSA, deletion also implies the revocation of access permissions associated with the entities governed by that agreement.

Once deleted, the object is no longer browsable in the Portal, as it no longer exists in active storage.

Deletion process

When the user selects the "Delete object" option (entity or relationship), the platform:

1. requests explicit confirmation of the operation, and

2. after confirmation, displays a message indicating that the deletion was completed successfully.

Restrictions for entities

If the object to be deleted is an entity, the following conditions must be met:

• It cannot have active relationships with other entities.
  If relationships exist, they must be deleted first. Only then can the entity be deleted.

• Removal of references in other objects.
  If the entity was included as a value in entity-type attributes of other objects (whether as a single entity, contained entities or entity arrays), the reference will also be automatically removed from those attributes.

Change organizational unit

This action allows transferring an entity to another Organizational Unit (OU). The OU change involves an update of the responsible parties associated with the asset (ownership, custody and validation) according to the organizational structure defined in Anjana Data Platform.

Change process

1. Selection of the new OU
   The user must select the destination organizational unit (new OU).
   Only those OUs where the user has permissions to register objects of the same subtype are shown as options.

2. Selection validation
   If the user selects the same OU where the entity is already located, Anjana Data Platform will display a notice requesting selection of a different unit.

3. Submission for validation
   After confirming the change, a transfer workflow is launched, which must be approved or rejected by the corresponding responsible parties.

4. Change application
   Once the transfer is approved, the entity belongs to the new Organizational Unit and its responsible parties are updated according to the destination OU.

   In the case of a DSA, this change also involves:

   • the removal of previous responsible parties from groups created by the DSA in integrated systems, and

   • the automatic addition of the new responsible parties associated with the destination OU.

Clone

La acción Clone permite crear un nuevo objeto (entidad o relación) como copia del original, generándolo siempre en estado Borrador y con un identificador único de objeto (ARI) distinta.

This action is available for any object, regardless of its status, as long as the user has permissions to create objects of that subtype.

Cloning behavior

• Al clonar, Anjana Data Platform solicita los datos necesarios para identificar el nuevo objeto y generar su identificador de objeto (ARI) .

• For a dataset, for example, a form opens where the user must provide values such as:

  • new name,

  • infrastructure,

  • technology/zone,

  • location

  • organizational unit (OU)

The resulting dataset maintains the same dataset fields as the original, as these will also be automatically cloned.

Once the process is complete, if the cloning is successful, the platform redirects the user directly to the newly created object.

Copy ARI to clipboard

This action allows copying the ARI (Anjana Resource Identifier) of the asset to the clipboard. The ARI is the unique internal identifier with which Anjana Data Platform references each object within the Portal.

Copying the ARI is especially useful for:

• including it in Entity type attributes during bulk creation or editing processes via Excel,

• sharing an unambiguous object identifier with other users or teams.

When executing the action, the platform displays a confirmation message indicating that the ARI has been copied successfully.

Copy or download snapshot

These actions allow obtaining the current snapshot of an asset (entity or relationship) in JSON format. The snapshot is a complete “photograph” of the object at the time of download and contains all its metadata, facilitating its consultation, traceability or technical reuse.

There are two options:

• Copy snapshot to clipboard: coloca el JSON en el portapapeles para poder pegarlo directamente en otra herramienta.

• Download snapshot: genera un archivo .json descargable con el contenido del snapshot.

Snapshot content

The snapshot includes:

• all attributes defined in the object template, with their current values,

• the internal identifier of the asset (ARI),

• and the associated native relationships.

Additionally, if the entity is the source or destination of approved relationships, the snapshot also includes the ARIs of the related entities, allowing the relational context of the object to be fully reconstructed.

When executing the copy or download action, the platform displays a confirmation message indicating that the operation was completed successfully.

Create new relationship

This action allows creating a relationship directly from the entity detail view, using it as the source or destination of that relationship. It facilitates the guided creation of links between assets without needing to leave the starting object.

Creation process

When "Create new relationship" is selected, Anjana Data Platform opens a guided creation window in which the user must:

1. Select the relationship type
   The dropdown only shows:

   • relationship types compatible with the subtype of the entity from which the action is initiated, and

   • those for which the user has creation permissions.

2. Define the relationship name
   The user enters the logical identifier of the relationship according to the operating model rules.

3. Complete source and destination

   • If the entity subtype is compatible as source, the Source field appears pre-filled with that entity.

   • If not, the Destination field appears pre-filled.

   In both cases, the opposite field is left empty for the user to complete, using the entity selection filters.

4. Invert source/destination (if applicable)
   Whenever the relationship type validations allow it, it is possible to swap the source and destination values from the window itself by clicking the swap button.
   

   

During the process, warnings may appear indicating compatibility restrictions (for example, that the relationship type only admits certain entity subtypes as source or destination).

Completion

Once all data is filled in and creation is confirmed:

• the relationship is registered in the catalog,

• a direct link is displayed to navigate to the new relationship,

• and, if the option "Keep values when creating object" is enabled, the window retains the entered information to facilitate creating similar relationships consecutively.

Deprecate/Discontinue

The Deprecate/Discontinue action allows initiating the status change of a native entity from Approved to Deprecated/Discontinued. This change always requires validation in an expiration workflow.

When this action is selected, Anjana Data Platform:

1. Requests the expiration date
   A window opens to define the expiration date of the current version when it becomes deprecated.
   If the object already has an expiration date set, the user can confirm or modify it.
   

   

2. Launches the deprecation workflow
   After confirming, the platform initiates a validation workflow for the corresponding responsible parties to approve or reject the deprecation.
   

   

3. Applies the status change
   If the deprecation is approved, the entity moves to Deprecated status.

Deactivate

La acción Deactivate permite cambiar el estado de una entidad o relación no nativa desde Approved a Disabled. Este cambio siempre requiere validación en un workflow de desactivación.

When "Deactivate" is selected, Anjana Data Platform:

1. Requests confirmation
   The user must explicitly confirm the operation before executing it.
   

   

2. Launches the deactivation workflow
   After confirmation, a validation workflow is initiated for the corresponding responsible parties to approve or reject the deactivation.
   

   

3. Applies the status change
   If deactivation is approved, the object moves to Disabled status.

In the case of a non-native entity included in a DSA, deactivation also implies the removal of permissions granted by the DSAs in which it was contained.

Unadhere

La acción Unadhere permite al usuario revocar su adherencia a un DSA y, con ello, perder el acceso a los datos asociados a dicho acuerdo.

This operation:

• does not require a validation workflow,

• is audited, and

• generates a DSA snapshot to reflect the update of the list of adherent users.

To execute this action, the user must be previously adherent to the DSA.
When selected, Anjana Data Platform requests explicit confirmation. Once confirmed:

1. the unadherence is executed,

2. the user's adherence to the DSA is removed, and

3. a message is displayed indicating that the operation was completed successfully.

Bulk unadhere users

The Bulk unadhere users action allows the DSA owner (role with ORGANIZATIONAL_UNIT_OWNER permissions over DSA in the DSA's OU) to revoke adherence and, therefore, data access for multiple users simultaneously.

This operation:

• does not require a validation workflow,

• is audited, and

• generates a DSA snapshot to reflect the update of the list of adherent users.

Bulk unadherence process

1. Access to the list of adherent users
   When executing the action, Anjana Data redirects to the Participants tab of the DSA, showing only the currently adherent users.
   

   

2. User selection
   The owner can select one or multiple users to unadhere.
   For security reasons, it is not possible to select users who are also DSA owners.

3. Confirmation
   After clicking "Unadhere", a review window opens showing the list of selected users to confirm that the unadherence is correct.

4. Execution and notification
   Once the operation is confirmed, the platform executes the unadherence and the owner receives a notification when the process has completed successfully.

Metadata download

La acción Download metadata genera un archivo Excel con el metadato completo del objeto seleccionado, incluyendo tanto los atributos estándar como los atributos personalizados definidos en el modelo operativo.

The downloaded Excel follows the same structure as the files used by Anjana Data Platform for creation or bulk editing of objects, so it can also be used as a base to update information and re-import it later.

Excel content

The file includes the following sheets:

1. Help sheet (Readme)
   Contains information for interpreting the Excel, including an explanation of the structure and the color codes used for the attributes.
   

   

2. Object metadata
   Includes all the main information about the asset, such as:

   • Internal ID of the object in Anjana Data Platform.

   • Template attributes, with their type, organized by menus and sections.

   • Organizational unit (OU).

   • ARI (unique internal identifier of the asset).

   • Status of the object.

   • Version (when applicable).

   • Creator user.

   • Creation date.

   • Last modification date.

3. Dataset fields metadata (only for datasets)
   When the downloaded object is a dataset, an additional sheet is included with the detail of all its dataset fields.

4. Custom attributes
   Contains an inventory of the extended attributes of the object, indicating for each:

   • reference to the object it belongs to,

   • attribute name,

   • attribute type,

   • value or values (including multilanguage if applicable).

Rename

La acción Rename permite modificar el nombre lógico de un activo. Debido a que el nombre forma parte del identificador único del objeto (ARI), esta operación está sujeta a condiciones de estado y versio.

When renaming is possible

Renaming can be performed in the following scenarios:

1. Objects in Imported, Rejected or Draft status

   • Only if no other version of the same object exists.

   • In this case, renaming does not launch a validation workflow.

2. Objects in Approved, Deprecated or Expired status

   • Only if no other version of the same object exists.

   • In this case, renaming launches the validation workflow associated with editing the object.

3. Administrator users via Admin API

   • If the user executes renaming with administration permissions via API, the operation does not launch a workflow, as it is an administrative action.

Renaming process

When "Rename" is selected, Anjana Data opens a window where the user must:

1. enter the new name, and

2. confirm the change.

If the user has permissions to rename with different roles (for example, a functional one and an administrator one), the platform will ask them to choose the renaming type:

• Regular, that is, with modification workflow launch, or

• Administrator, i.e., without workflow,

applying the rules described above.

Effects of renaming

When renaming requires a workflow, changes are applied only after approval. Once approved, renaming impacts various elements of the system:

• Object name (attribute name).

• ARI of the object (internal identifier).

• Historical records associated with the object.

• Workflows affecting the object.

• Notifications issued (both the object and the associated text).

• Node or relationship in lineage.

Additionally, if the asset is an entity, renaming also updates:

• all its occurrences as source or destination of relationships,

• the name of the internal relationships where it participates,

• the ARIs of the relationships that contain it,

• any reference to the entity in Entity type attributes of other objects,

• and occurrences within entity arrays.

Actions on datasets with a high number of fields

In datasets containing a high number of dataset fields, certain actions may require intensive processing due to the volume of internal operations they involve. To avoid prolonged waiting times in the detail view, Anjana Data Platform manages these actions in the background.

When the user executes an action that causes significant changes in a large dataset —such as a status change or the generation of a new version— the application:

1. initiates the processing of the action,

2. automatically redirects the user to the Data Portal, and

3. displays a notice informing that the operation may take time to complete.

The actions that can trigger this behavior include:

• Save changes in the approved dataset template.

• Add or remove dataset fields in an approved dataset.

• Submit for validation a dataset.

• Clone un dataset.

• Delete a dataset.

In these cases, Anjana Data will display a notification message indicating that the operation is being executed and will complete in the background.