Workflow Overview

Overview

There are 2 types of models in the repository:

Imported Models are the models associated with an import bridge to be populated through the model harvesting process. Many times these models are referred to as technical models, however they are also sometimes considered business models when imported from business applications or business intelligence (BI) tools.
Custom Models are instantiations of a custom model type in the metamodel and may be populated via the UI, bulk CSV import, or the REST API. They are commonly referred to as business models, however they are also sometimes considered technical models withing the domains of reference data, business rules, etc.

Custom models can be defined for the custom metamodels needed in many data governance related domains such as data management, reference data, data quality, data trust, data security, data sharing and shopping, data issue management, business rules, business process modeling and improvements, vertical market specific business applications and regulation compliance. Administrators can use a new MANAGE > Metamodel capability to define their custom models with the full power of object modeling, all the way the graphical editing of UML class diagrams for each custom models.

By default, custom model will have no workflow requirement, thus there will be no formal review and approval process. However, all Metadata Viewing, Editing and Management capability object role assignments may be used to manage access and update. You may see the functions without workflow defined below.

MetaKarta also provides a very flexible and complete set of possible workflow and publication processes that you may employ. When your organization would like to have a more formal development process that involves multiple users with various review/approval/publishing roles you can enable workflow. The workflow is a prepackaged sequence of activities around term proposal, editing, review, acceptance, publishing and depreciation. It is a flexible process that can be customized to require only publishing activity, approval with or without review, approval and review by one or multiple users, etc.

All the functions of either an imported or a custom model are affected by the imposition of a workflow, especially in terms of changes to the object classes which are under workflow requirements. As an example, the we have an example of a glossary (a type of pre-defined custom model) under workflow and how these functions are affected along with how to enable the workflow in the first place.

We will cover the concepts of the workflow using a Glossary model as an example. Differences for imported models are identified.

In MetaKarta, a glossary is a self-contained and extensible metamodel-based collection of business objects referred to as terms. In turn, the terms may be directly linked (be used to document objects) to objects in the repository, such as tables and columns in a data model, may be associated with data classes to support automatic data class discovery and classification of objects, and also may be semantically mapped to objects throughout the rest of the repository. Once a term is defined, classified or mapped, the objects will have semantic lineage results such as definition lookups or term semantic usage across any configuration which contains the glossary and mapped or classified objects.

Custom Model Workflow

By default, a custom model, like a glossary will have no workflow requirement (including no approval process). In this simple state changes made to the custom model are reflected immediately throughout the system. This is a very useful mode for organizations that do not want the complexity of a workflow process. It is also useful for organizations when they are first building and populating a glossary (or any type of custom model) and related semantic mappings, encouraging rapid building of the glossary and crowd-sourcing.

MetaKarta also provides a very flexible and complete set of possible workflow and publication processes that you may employ. Choose to enforce workflow carefully, as once selected it cannot be undone, though many of the specifics may be changed.

For the rest of the workflow discussion, we will refer to a glossary model as it is the most common workflow example.

When your company would like to have a formal glossary development process that involves multiple users you can enable the glossary workflow. The workflow is a prepackaged sequence of glossary activities around term proposal, review, acceptance, publishing and/or depreciation. It is a flexible process that can be customized to require only publishing activity, approval with or without review, approval and review by one or multiple users, etc.

The glossary must have a default version before workflow may be enabled.

Custom Model Workflow Object Roles

A user with the Workflow Management capability object role assignment on a glossary can enable the workflow and assign the following workflow object roles to one or more terms or the glossary itself:

Workflow Editor
Workflow Reviewer
Workflow Approver
Workflow Publisher

A workflow object role can be assigned for any object (term) in the glossary for any user or group.

One must have both the Workflow Editor AND the Metadata Editor capability object role assignment to actually edit terminology for a glossary under workflow. In general this consideration is not important as the default workflow roles which may be assigned are already defined to have the proper metadata capabilities as well as workflow capabilities

Custom Model Workflow Process Options

The workflow process applies to all object in a glossary.

When the workflow is enabled, some restrictions apply to the ability to perform certain actions:

You cannot delete a term that contains published terms
You cannot publish term until its parent is published (when creating them together).

A status of Workflow Published for a term, means whether the term was ever published, it does not mean it is currently in the Published state. If you create a new term and transition it from Draft → Under Review → Approved, you won't see the Workflow Publishe" = true.

A simple and complete workflow process with all possible paths is in the diagram below:

The next diagram presents the workflow in a swim lane diagram with the workflow object capabilities/roles required for each workflow state and action.

You can enable the workflow when you create the glossary or after. You cannot disable the workflow after it has been enabled. However, you may change some of the options.

Workflow Action	Workflow object role
	Editor	Reviewer	Approver	Publisher
Propose Candidate	X	X	X	X
Create Draft	X
Discard	X
Start Review	X
Mark for Deprecation	X
Submit for Approval	X
Send to Draft	X
Recommend Approval		X
Request Change		X
Reject (Awaiting Approval)			X
Approve			X
Edit (Approved)				X
Publish				X
Deprecate				X
Create, edit or remove attributes and associations	X	X
Create comments	X	X	X	X
Edit or remove comments	X	X	X
Create, edit or remove attachments	X

Custom Workflow transition

When working with individual objects which are at some point in the workflow process, workflow transition buttons prompt you with possible actions, e.g., if a term is in Draft status, then the icons would include:

Start Review
Submit for Approval
Mark for Deprecation
Discard

Custom Model Properties Excluded from the Workflow Process

The following properties / addenda are outside of the workflow process:

Labels
Attachments
Curation with comments

Thus, with the appropriate capability object role assignment:

Label Editing
Attachment Editing
Certification Editing
Endorsement Editing
Warning Editing
Comment Editing

you may edit these properties without a workflow transition required.

Custom Model Versioning and Workflow

When you enable workflow MetaKarta creates another version of the glossary named Published. The Published version is the one whose contents are to be presented to most of the users. Its contents are not directly editable (with or without permission). Instead, one edits the contents of Development version and then uses the Publish workflow step to change what is in the Published glossary.

The glossary version you are given access to when using the Browse/Explore/Search/Worksheets/Collections/etc. features is always determined by what your workflow permissions are. In particular, you will have access to:

The contents of the Published version the glossary if you do not have any Workflow capability object role assignments, and you will not have any ability to edit the glossary or see current edits and workflow states. You will only see what was published.
The contents of the Development version of the glossary if you do not have any Workflow capability object role assignments, and you will have the ability to see glossary object in their current workflow status

In this way, general users are given access to the contents of the Published glossary, and users who are editing the workflow enabled glossary will also be given access to the contents of the Development glossary.

In fact, you will also see a similar behavior in the Repository Manager.

When you expand the glossary to show its versions, you will see both the Published and Development versions, no matter what Workflow capability object role assignments you may have.

In addition, if you open any configuration version containing the glossary, the UI will show that that configuration version contains the:

Published version of the glossary if you do not have any Workflow capability object role assignments,.

Development version of the glossary if you do not have any Workflow capability object role assignments, and you will have the ability to see glossary object in their current workflow status

You will always see this version as the member of any configuration version and trying to assign another version will not be possible. It is entirely system managed and presented to the user this way. It can be a bit confusing to casual users, but generally casual users do not have access to the Repository Manager.

In terms of implementation, it is the Published version of the glossary that is associated with any configuration version, even though you may see a different version in the UI.

Finally, you may associate an archived (historical) version of a glossary with a configuration, thereby making it the Published version for the purposes of presentation.

How to create and manage a glossary.

Imported Model Workflow

Changes to an imported model, such as a database model, are limited. As an imported model is first and foremost a faithful representation of the database (or otherwise) from which it was imported, then one cannot change the imported characteristics. Thus, for a imported database model, one cannot simply add or removed tables, columns, views, etc., and cannot edit/change the datatypes, validation rules, etc. They must continue to reflect what is in the original source metadata that was imported.

However, one may document (business name, definition, description, etc.), curate (e.g. certification), provide sensitivity label information, classify and otherwise update custom attribution to the objects in imported models. Consequently, they may be placed under a workflow process.

By default, an imported model, like a database, will have no workflow requirement (including no approval process). In this simple state changes made to the glossary are reflected immediately throughout the system. This is a very useful mode for organizations that do not want the complexity of a workflow process. It is also useful for organizations when they are first building and populating a glossary and related semantic mappings, encouraging rapid building of the glossary and crowd-sourcing.

MetaKarta also provides a very flexible and complete set of possible workflow and publication processes that you may employ. Choose to enforce workflow carefully, as once selected it cannot be undone, though many of the specifics may be changed.

When your company would like to have a formal glossary development process that involves multiple users you can enable the glossary workflow. The workflow is a prepackaged sequence of glossary activities around term proposal, review, acceptance, publishing and/or depreciation. It is a flexible process that can be customized to require only publishing activity, approval with or without review, approval and review by one or multiple users, etc.

Imported Model Workflow Object Roles

A user with the Workflow Management capability object role assignment on an imported model can enable the workflow and assign the following workflow object roles to one or more terms or the imported model itself:

Workflow Editor
Workflow Reviewer
Workflow Approver
Workflow Publisher

A workflow object role can be assigned for any object (term) in the imported model for any user or group.

One must have both the Workflow Editor AND the Metadata Editor capability object role assignment to actually edit objects for an imported model under workflow. In general this consideration is not important as the default workflow roles which may be assigned are already defined to have the proper metadata capabilities as well as workflow capabilities

Imported Model Workflow Process Options

The workflow process applies to all object in an imported model.

When the workflow is enabled, some restrictions apply to the ability to perform certain actions:

A status of Workflow Published for a term, means whether the term was ever published, it does not mean it is currently in the Published state. If you create a new term and transition it from Draft → Under Review → Approved, you won't see the Workflow Published" = true.

A simple and complete workflow process with all possible paths is in the diagram below:

One cannot propose new objects or delete existing object in an imported model under workflow ss an imported model is first and foremost a faithful representation of the database (or otherwise) from which it was imported.

The next diagram presents the workflow in a swim lane diagram with the workflow object capabilities/roles required for each workflow state and action.

You can enable the workflow when you create the imported model or after. You cannot disable the workflow after it has been enabled. However, you may change some of the options.

Workflow Action	Workflow object role
	Editor	Reviewer	Approver	Publisher
Create Draft	X
Discard	X
Edit	X
Start Review	X
Submit for Approval	X
Send to Draft	X
Recommend Approval		X
Request Change		X
Reject (Awaiting Approval)			X
Approve			X
Publish				X
Create, edit or remove attributes and associations	X	X
Create comments	X	X	X	X
Edit or remove comments	X	X	X
Create, edit or remove attachments	X

Imported Model Workflow Transition

When working with individual objects which are at some point in the workflow process, workflow transition buttons prompt you with possible actions, e.g., if a term is in Draft status, then the icons would include:

Start Review
Submit for Approval
Discard

Properties Excluded from the Workflow Process

The following properties / addenda are outside of the workflow process:

Labels
Attachments
Curation with comments

Thus, with the appropriate capability object role assignment:

Label Editing
Attachment Editing
Certification Editing
Endorsement Editing
Warning Editing
Comment Editing

you may edit these properties without a workflow transition required.

Imported Model Versioning and workflow

When you enable workflow MetaKarta treats the latest version of the imported model as the one that is active for editing. This version is the one whose contents are to be presented to most of the users. Its contents are not directly editable (with or without permission). Instead, one edits the this version and then uses the Publish workflow step to change what is seen by most users (without workflow roles).

The ability to edit an imported model under workflow is always determined by what your workflow permissions are. In particular, you will have access to and see:

The contents without unpublished edits model if you do not have any Workflow capability object role assignments.

In this way, general users are given access to the contents of the Published objects, and users who have a workflow role for the workflow enabled model will see the in progress edits and workflow statuses before they are published.

Object Management Dashboard

My Workflow Tasks provides an interactive dashboard identifying objects and the actions that need to be taken for workflow models in a configuration by the logged in user.

Recently Changed Objects provides an interactive dashboard (as part of a worksheet) identifying objects which have changed.