ONE Desktop ONE DQG ONE MDM ONE RDM ONE Runtime Server
latest (15.1.0) 14.5.x 13.9.x 13.8.x 13.7.x 13.6.x
User Community Service Desk Downloads
If you can't find the product or version you're looking for, visit support.ataccama.com/downloads

Workflows

Workflows refer to access request and review request workflows.

Access request workflows offer additional automation for requesting data access changes in ONE. You can use it to ask for a higher level access to an asset, after which your request is approved or rejected by the person assigned to this task. For more information about access levels, see Access Levels.

Review request workflows provide additional automation for requesting reviews of changes made to data assets and publishing these changes in ONE. If you have an editing access level on an asset, you can use it when implementing changes on an asset to send them for review. The task assignee can then approve and publish your changes or reject them.

There is an additional workflow called Approval Workflow Migration that you must complete when you first start the application after upgrading from a previous version of ONE.

Before this is done, you cannot proceed with the review and publishing of request tasks and the Waiting for complete configuration state is displayed on review request tasks. For more information, see the one-gen2-upgrade-guide.adoc.

Prerequisites

To be able to request access to an asset, you need to make sure that the workflows:ableToStartRequestDataAccess trait is enabled on this entity. For more information, see Traits.

Requesting data access can be enabled only on the following entities: * Catalog item * Source * Location * Connection * Monitoring project

How to access workflows

To view the list of workflows, go to Tasks And Workflows > Launched workflows tab.

600

From the Launched workflows tab you can:

  • See all Active and Finished access request workflows. All new requests are listed under the Active section, while the processed ones are listed under the Finished section.

  • See the workflows details by the parameters:

    • Workflow name: Name of the workflow.

    • Started by: The creator of the request.

    • State: Current state of the access request task: waiting for approval, permission granted, permission declined.

    • Preview: Select the eye icon to see the list of possible states.

    • Created task: Open the link to view the related task.

    • Start time: The time when the task was created.

    • Duration of current state: How long the task has been in the current state.

To view the configuration of the access request workflow, go to Tasks And Workflows > Workflows tab.

600

From the Workflows tab you can see the default settings of the workflow and edit the assignee:

  • Workflow name: Request Data Access, Review workflow and, if the review workflow migration was not completed, the Approval Workflow migration.

  • Owner: system. This means that you cannot delete the workflow as it is a default one. It doesn’t represent stewardship rights. For more information about how to change the stewardship for the workflow, see [How to change assignee].

  • Preview: The list of all possible states of the access request task.

  • Last run date: The date when the workflow was last run.

  • Active run: Number of unprocessed requests.

  • Archive run: Number of processed requests.

Request data access workflow

Change assignee

Only users with MMM_admin identity provider role can change the default assignee of workflow requests.

The default assignee can either manage the request or redirect the task to another user.

To change the default assignee of all access workflows:

  1. Go to Tasks and Workflows > Workflows.

  2. In the three dots menu next to the workflow select Edit.

  3. Specify the stewardship:

    400

    • Default assignee (by stewardship): Select if you want the assignee to be assigned by default stewardship settings, if any, of the entity for which access is requested.

    • Default assignee (when stewardship isn’t set): Select the group and, optionally, governance roles as the assignee responsible for all access requests.

    • Backup assignee (when other options fail): Select the user or an identity provider role who can resolve the access request in case another assignee is not available.

  4. Select Save.

Request data access

When a user has only View metadata` access level, tabs that contain data are restricted for this user and suggest requesting access from the tab itself:

400

To request access from the entity:

  1. From the entity you want to change your access rights for, select the three dots menu and then Request access.

    200

  2. Review the following information:

    400

    1. Type: Prefilled task type.

    2. Access level: The access level you want to get on this entity.

    3. Priority: The priority of the task.

    4. Description: The reasons for providing the requested access level.

    5. Entity: Prefilled entity type and instance for which you are requesting access changes.

  3. Select Submit.

    After submitting the task, both the creator and assignee see:

    1. A notification about the new task in the Notification Center.

      200

    2. The task on the kanban board. For more information about working with the kanban board, see Tasks.

    3. The task in the Active state on the workflows overview tab.

Approve or reject access request

When a new task of the Access Request type is added to the kanban board, the assignee can do the following:

  1. Go to the kanban board or to the task detail view from the board or from the Notification Center. The new task has waiting for approval status.

  2. In the subtask, select one of the following to change the task status:

    400

    1. Approve to automatically grant access to the creator of the task on the specified entity. This changes the task status to permission granted.

    2. Reject to reject granting access. This changes the task status to permission declined.

  3. Optionally, you can change the task assignee. For more information, see Tasks.

After approving or rejecting the access, the task is automatically moved to the Complete column. The workflow is also moved to the Finished list on the Workflows Overview tab.

Change the review workflow assignee

Only users with MMM_admin identity provider role can change the default assignee of workflow requests.

The default assignee can either manage the request or redirect the task to another user.

To change the default assignee of all review workflows:

  1. Go to Tasks and Workflows > Workflows tab.

  2. In the three dots menu of the Review workflow, select Edit.

  3. Change the configuration of the review access assignee:

    400

    • Approver type: Specify the type of approval role. By default, it is stewardship, which means that the tasks are assigned to the stewardship group.

      At the first configuration during the migration, the type of the approver is set to migrated to indicate that it needs to be specified, otherwise, the migration is not completed.

    • Global roles IDs: Specify the global roles IDs to assign the tasks to users from the owner group with specific roles only.

    • Conditions: Specify the entityType and the filters to enable the review workflow on entities. By default, review workflow is enabled only on policies and terms.

      • entityType: You can specify any entity on which you want to configure the workflow.

      • filter: Specify the condition under which the workflow is triggered using AQL expressions. For more information, see Search using AQL Expressions.

        To find the list of properties you can use in the AQL expression, open the entity details in Metadata Model and see its properties. For example, go to Metadata Model > term > validationRules property > object termValidationRules to see the properties you can use in the filter (boolean enabled and array ruleInstances).

    • Business state: Specify the state of the task for the review workflow. This is a custom message that is shown on the task card when the request is created.

    Example configuration

    In the following example, you can see a configuration for the terms that have validation rules to be reviewed by a specific group of users instead of the owner group according to the stewardship model.

    [
  {
    "approver": {
      "type": "stewardship",
      "globalRoleIds": []
    },
    "conditions": [
      {
        "filter": null,
        "entityType": "term"
      },
      {
        "filter": null,
        "entityType": "policy"
      }
    ],
    "businessState": "WAITING_FOR_REVIEW"
  },
  {
    "approver": {
      "type": "group",
      "groupId": "15bbce34-0000-7000-0000-00000047025b"
    },
    "conditions": [
      {
        "filter": "validationRules.enabled = true and validationRules.ruleInstances.count() > 0",
        "entityType": "term"
      }
    ],
    "businessState": "WAITING_FOR_DATA_OFFICE"
  }
]

  4. In Backup workflow settings, specify a group that can manage the task in case the configured approver is not available (by default, this is the group with stewardship).

    400

  5. Select Save.

Troubleshooting review workflow

In case you have created a configuration on an entity and it does not work, you can check if this entity has the hasNoWorkflow trait assigned that blocks the workflow:

  1. Go to Metadata Model > your entity > traits.

  2. Remove the trait and publish your changes.

For more information about traits, see Traits.

By default, this trait is assigned to the following business entities:

  • connection

  • location

  • source

  • credential

  • connectionWithCredentials

  • relationshipType

  • catalogItemRelationship

  • termRelationship

  • globalRole

  • group

  • observabilityIssue

  • dataQualityIssue

  • dataQualityAnomalyIssue

  • anomalyDetectionIssue

  • volumeIssue

  • schemaChangeIssue

  • termDetectionIssue

Was this page useful?