The Tag Schema Common Actions Service is a Kyndryl Modern Operations Applications feature that allows you to set policies governing the use of tags in the Kyndryl Modern Operations Applications to help you organize your reports, and monitor and enforce compliance. The tag schema service supports both internal and external (provider side) tags.

The service ensures that tags applied at the provider and updates or modifies them as needed to comply with the tag schema defined in the Kyndryl Modern Operations Applications. You can also use your own tools, other services or the provider’s native portal for tag management while still being able to track against a central tag schema to ensure compliance.

The highest level is the tagging strategy, which represents how you want to manage tagging across your system. The tagging strategy consists of one or more tag schemas, which allow you to place rules on how tags are created in your system. Each tag schema consists of one or more tag definitions and one set of schema conditions.

Schema conditions are the conditions under which the tag schema is enforced. The tag definitions consist of the key and value for the tag, and what

key:value

conditions are allowed by the tag schema. This system allows you to set up rules for your tags that are enforced under any set of conditions that you want to set up.

You can use a tag schema, for example, to ensure that a set of basic tags are consistent across your enterprise, ensuring that you can access and monitor your environment with confidence. You can, for example, set rules to ensure that a standard set of tags is attached to everything in your system including the existence of those tags (make them mandatory), the type of those tags (such as string), and what values those tags are allowed to have.

You can create a standardized tag schema across the Kyndryl Modern Operations Applications and your service providers. The schema allows apps to apply tags that are considered standard to their application specific workflows, such as the

order_id

tag that Enterprise Marketplace will always set. This system allows you to enforce control and governance for usage of tagging across the Kyndryl Modern Operations Applications within an application's user interface (UI).

There are two types of tags:

Providers will have their own tag schema guidelines. You can create a tag schema to enforce these rules to ensure that the tags in the Kyndryl Modern Operations Applications will meet the rules that the provider has set for their tags.

The system also allows you to manage dynamically generated tag values, allowing your users to create tags while enforcing their required characteristics.

Any app, integration, or automation that supports dynamic resource groups (such as Governance Console today), can use the defined tag schema for dynamic resource member relationships to use the defined policy for other application console governance use cases.

Tag Schema uses provider Asset Ingestion Accounts.

You can make tag definitions dependent on the value of other tag definitions. For example, you might want to provide a list of campus locations in a region when a user selects that region or apply the tag 'confidential' to anything from a particular department. This is referred to as being 'determined by' and 'determines.' Any number of tag definitions can be nested in this way.

In the Kyndryl Modern Operations Applications, the following types of tag schemas are available:

You can use the following user roles to manage tag schemas:

Role	Tag Schema Viewer	Tag Schema Admin
View global tag schemas	Yes	Yes
Create, modify, and delete global tag schemas	No	Yes
View global tag schema conditions	Yes	Yes
Create, modify, and delete global tag schema conditions	No	No
View tag definitions	Yes	Yes
Create, modify, and delete tag definitions	No	Yes
View tag definition details	Yes	Yes

In support of Cost & Asset Management (CAM), tag schemas offer the following capabilities:

The tag schemas also provide the following functions:

You can make tag definitions dependent on the value of other tag definitions. For example, you might want to provide a list of campus locations when a user selects a specific region or apply the tag 'confidential' to anything from a particular department. These are divided into enabling tags, which determine something about the enabled tag in a parent-child relationship.

An enabling tag can be linked to multiple enabled tags. An enabled tag can also be an enabling tag for other tags. There is no limit to how many layers of enabling and enabled tags that you can create.

For some example scenarios of tag definition dependencies, see Tag definition scenarios.

The following types of enabled and enabling relationships are supported in the Kyndryl Modern Operations Applications.

Resulting type of tag definition	Possible values for “Mandatory”	Related/Enabled value?	Supported	Use case for creating this tag definition
Enabling	Yes	This works as a “parent” in a hierarchy of tags. Other tags can have related values defined to this tag	Yes	Tag is mandatory for all services for all accounts at all providers
Enabling	Conditional	Undefined	Yes	Tag is mandatory for some services and accounts at some providers
Enabling	No	Undefined	Yes	Optional to exist at provider
Enabling	No	Undefined	No	Tags Definitions MUST have either provider, accounts, service types defined, or be related to another tag definition that defines these conditions
Enabled	Yes	Yes (must be related if this is a child in a hierarchy)	Yes (filter only to provider, accounts, service types from parent tag)	Tag is mandatory, is enabled based on a specific value from another tag Needs to exist at all services for all accounts and at all providers Tag is enabled by another tag definition, the provider/account conditions are managed at the enabling tag definition Problem with chained refs where parent does not have any conditions Children might or might not have conditions If parents have provider/account/service types defined, children cannot supersede that
Enabled	Conditional	Yes	Yes	Could be mandatory, is enabled based on a specific value from another tag Provider, accounts, service types from the child CANNOT be a superset of the parent Provider, accounts, service types from the child CAN be a subset of the parent’s
Enabled	No	Yes	Yes	Optional to exist at provider, is enabled based on a specific value from another tag
Enabled	undefined	Yes	Yes	May or may not be mandatory, enabled by some other tag definition and derives conditions from the enabling tag definition Provider, accounts, service types from the child CAN be a null set