Skip to content

Verification enforcer

Source code

The verification enforcer pipeline ensures any asset marked verified meets a minimum standard, and if it does not then it will automatically be reverted to draft.

Use cases

  • Enforce that assets have a certain amount of context before they can be considered verified

Configuration

Logic

  • Asset types: the types of assets to enforce these minimum standards against.
  • Must have: the characteristics an asset msut have to meet the minimum standard to be verified. If any of these characteristics are missing, the asset cannot be verified.
  • Enforcement message: if an asset has been marked verified but does not meet the minimum standard, this message will be attached when it is automatically reverted to draft.

Runtime

  • Run as...: choose how you want the workflow to run, either as the user who configures it (default) or through a specific API token's permissions.

    Relies on permissions of this actor

    Note that the pipeline will have the same permissions as the actor you choose here. If you run as the user configuring the workflow, and that user does not have access to modify certain assets, then the pipeline will not have access to update the scores for those assets, either.

What it does

On any asset creation or change, if the asset is marked verified the pipeline will check whether it has all "must have" characteristics configured above:

  • If so, the asset will be left alone (no changes).
  • If not, the pipeline will:
    • Change the certificate on the asset to DRAFT
    • Leave the "enforcement message" configured above against the certificate
How it works

Configuring the package will pass over your configuration to the always-on pipeline, which should automatically sync the configuration and begin verification enforcement within a few minutes of the configuration process completing.

The on-going enforcement process then involves:

  1. Any change to any asset you configured (whether created or updated), when that asset is also verified, will trigger an enforcement check.
  2. The current view of the asset will be queried from Atlan, looking up all of the configured "must have" characteristics for that asset. This ensures even if events arrive out-of-order or there is some delay before they are processed the enforcement will always reflect the latest information we know about the asset.
  3. The pipeline will validate that all of the "must have" characteristics are present on the asset.
  4. If they are not, the asset will be updated with a new certificate of DRAFT and the configured enforcement message (otherwise it will be left as-is, unchanged).