Editing Custom Validations

1. Inspect the data chain object that you want to edit a custom validation for.
2. Perform an action:
   • For applications, node types, hierarchy sets, and dimensions in Universal applications: On the Validations tab, click Edit.
   • For dimensions in applications other than Universal: On the Validations tab, click the Custom sub tab, and then click Edit
3. On the General tab of the validation inspector, click Edit to edit the validation name or description.
4. On the Definition tab, define the validation by entering the following information:
   • Enabled flag: Specify whether or not a custom validation is enforced. Validations are disabled by default, and you can only enable them when these conditions are met:
     • A valid expression is defined
     • At least one trigger action or property is configured
     • A failure message is defined

     Note:

     You can also enable or disable validations from the Validation tab of the node type or hierarchy set inspector. See Enabling, Disabling, or Deleting a Custom Validation.
   • Expression: Click Define Expression to open expression builder and then define the business logic for the validation. See Using Expressions to Define Custom Business Logic.

     The expression for a validation must return a Boolean value. If the expression returns a value of True, the validation is passed. If the expression returns a value of False, the validation fails and the failure message is displayed.

   • Trigger Action: Select one or more request actions that will cause the validation to run, or select the All check box to select all actions.
   • Trigger Properties: Select one or more properties that will cause the validation to run if they are updated, or select the All check box to select all properties.
     • For node type validations, all properties that are assigned to that node type are available to be selected.
     • For hierarchy set validations, all properties that are assigned to any node type that is referenced by the hierarchy set are available to be selected.

     Tip:

     Validations are run for every trigger action and trigger property in a request. That means that if you add several trigger properties and all of them fail, you will receive several failure messages. You should add the minimum number of trigger properties or actions that still enforce your business logic on a request.

   • Request Validation Scope: Select the context in which the validation is run when validating a request.
     • Node (default): The validation is evaluated in the context of the node in the request action. The validation is triggered when changes are made to the node itself.
     • Parent: The validation is evaluated in the context of the parent of the node in the request action. When changes are made to a node in a hierarchy, the parent of the node in the request action is evaluated for any validations with a scope of Parent.
     • Previous Parent: The validation is evaluated in the context of the previous parent node (the parent that the node was moved from) when the parent is being changed in a request.

       Note:

       When you set the scope to Previous Parent, the Trigger Action is set to Move and the Trigger Properties are set to None. These settings cannot be changed.
     • Both Parents: The validation is evaluated in the context of the both the previous parent node (the parent that the mode was moved from) and the new parent (the parent that the node was moved to) when the parent is being changed in a request.

       Note:

       When you set the scope to Both Parents, the Move action is added to the Trigger Actions. You can specify additional trigger actions and trigger properties. However, the previous parent will be evaluated only for move actions.

     Note the following about request validation scope:

     • The scope is used when validating request items only. When validating viewpoints or exports:
       • If a validation has a scope of Parent or Both Parents, the scope setting is ignored and the validation is run using the Node scope (that is, the validation is run on the node where the validation is defined).
       • If the validation has a scope of Previous Parent, it is not run during the validation operation.
     • Validations with a scope of Parent, Previous Parent, or Both Parents are not run when validating requests for a list viewpoint.
     • When validating requests, trigger actions and properties are evaluated based on the child action performed in the request. For example, a validation with a scope of Parent and a trigger property of Core.Description is evaluated any time the description property is updated on a child node of that parent.
   • Request State: Select the state in which custom validations are run in the context of a request:
     • Committed (Default): The validation is evaluated against data after the request items and actions have been applied to the viewpoint. Nodes that are removed or deleted in the request are excluded when evaluating data conditions in the Committed state.
     • Visualized: The validation is evaluated against data before the request items and actions have been applied to the viewpoint. Nodes that are removed or deleted in the request are included when evaluating data conditions in the Visualized state.

       Note:

       Validations using the Visualized state are only run when validating request items and do not run when validating a viewpoint.
   • Severity: Select the severity for the validation (Error, Warning, Ignore) at the Request Submit, Approve, and Commit stages, as well when validating a viewpoint and exporting a dimension. See Configuring Validation Enforcement and Severity.
   • Failure Message: Enter the message to display to users if the validation fails.

     Tip:

     When configuring validation failure messages, provide the context of the validation (node or parent) in order to help you identify where the issue was found.
5. Click Save.