Add Value Transformation

This Transformation page makes it possible to add additional values to the claims of a token. In terms of the features it supports, it is identical to “User Independent Values for Claims” and “Service Provider Specific Claims” that existed in version 3.1. As of version 3.2, these two settings no longer exist, but they are replaced by the “Claim Value Transformation” object. If you are upgrading your solution, fear not—your earlier settings will automatically be converted to the mentioned new object so that your pipeline will function identically.

What this Transformation object will do—regardless of how the claim set looks when reaching this step in the pipeline—is add the values of this object to the claim set.


The Transformation consists of the following sections:

Claim Transformation Name: Give the Transformation object a name that will make it easy to recognize when adding to the pipelines of Authentication and Protocol Connections.

Culture: Because the expression might be using and comparing numbers, it is important for the system to know which culture is used in order to know whether a comma or a dot indicates a decimal point. Currently, only two cultures are supported, Danish (a comma is a decimal point) and American (a dot is a decimal point). These should cover the needs of other cultures in regard to this issue.

Owner Organization: This represents the organization that the Claim Transformation is added to.

Execute before loading claims from local store:By default, a Claim Transformation rule is executed after claims from the local store are loaded for a principal. Check this option to let it execute before the load.

Conditions: It is possible to specify that the Transformation object is only applied to a pipeline given certain conditions of the token or user are in place. Conditions include:

Add Claim Value Transformation: This represents the specific values that will be added to claims of a token when passing by this step. The values will always be an addition to the existing values for a token’s claims rather than overwriting them. If, for example, the email claim already has a value for the token before reaching this Transformation object and another value is stated in the object, then the token will have two values for the email claim after this step.