Data Rule (Node Type)

From Grooper Wiki
Revision as of 09:42, 8 May 2026 by Rpatton (talk | contribs) (// via Wikitext Extension for VSCode)

This article is about the current version of Grooper.

Note that some content may still need to be updated.

2025 20232021


flowsheet Data Rules are used to normalize or otherwise prepare data collected in a data_table Data Model for downstream processes. Data Rules apply conditional logic to data extracted from documents (folder Batch Folders).

  • Each Data Rule executes a "Data Action" which do things like computing a field's value, parse a field into other fields, perform lookups, and more.
  • Data Actions can be conditionally executed based on a Data Rule's "Trigger" expression.
  • A hierarchy of Data Rules can be created to execute multiple Data Actions and perform complex data transformation tasks.

WIP

This article is a work-in-progress or created as a placeholder for testing purposes. This article is subject to change and/or expansion. It may be incomplete, inaccurate, or stop abruptly.

This tag will be removed upon draft completion.

Introduction

A Data Rule is a configurable rule that applies conditional logic to extracted data. Data Rules are typically used after extraction to transform values into the format your downstream systems require, or to enforce business requirements that are easier to express as a rule than as extraction logic.

Unlike extractors (which focus on finding data on the document), Data Rules focus on fixing, moving, combining, and validating the data once it has been captured into a Data Model.

What a Data Rule runs against (scope)

A Data Rule runs against instances of a selected container. The container is chosen using the rule's "Scope" property:

  • If the "Scope" is set to a Data Model, the rule executes once on the root document instance.
  • If the "Scope" is set to a Data Section (and the section is multi-instance), the rule executes for each section record (each Section Instance).
  • If the "Scope" is set to a Data Table, the rule executes for each row (each Table Row Instance).

This is important because many Data Actions operate on fields within the current record/row, and the meaning of “source” and “target” depends on what the rule is scoped to.

Conditional execution (Trigger, True Action, False Action)

A Data Rule can optionally use conditional logic to decide what should happen:

  • The "Trigger" property must be configured with a Boolean expression.
  • When "Trigger" evaluates to True:
    • The "True Action" runs.
    • Any child Data Rules (nested under the current rule) also run.
  • When "Trigger" evaluates to False:
    • The "False Action" runs (if configured).
    • Child Data Rules are skipped.
    • If no "False Action" is configured, the Data Rule just does not run.

If the Trigger property is blank, the Data Rule will always run.

How Data Rules differ from other conditional components

Data Rules are purpose-built for manipulating and validating extracted values inside the Data Model hierarchy (document, section record, or table row). There are other Grooper components that also use conditional logic (for example, conditional paths in a Batch Process), but those typically control workflow routing or when a step runs. Data Rules control how extracted data is modified within the document's data structure.

How to configure a Data Rule (step-by-step)

  1. In Grooper Design, create or select a Data Rule (commonly stored in a Content Type's Local Resources Folder).
  2. Select the Data Rule and set:
    1. "Scope" to the Data Model, Data Section, or Data Table you want to process.
    2. (Optional) "Trigger" to define when the rule should apply.
    3. "True Action" to define what happens when the trigger is met (or always, if Trigger is blank).
    4. (Optional) "False Action" to define what happens when the trigger is not met.
    5. (Optional) "Shortcut Keys" if you want a manual shortcut in review tools that support it.
  3. (Optional) Add child Data Rules under the rule to build a multi-step decision tree.


Testing and troubleshooting

  • If you need to test a rule interactively during Review, you can run it from a field container using the Run Rule command:
    • Alt + R
  • If a rule does not appear in the list, verify:
    • The rule’s "Scope" is compatible with the selected container.
    • The rule is stored where it is accessible for the Content Type you are reviewing.
  • If a rule never runs:
    • Confirm "Trigger" is either blank or evaluates to True for the current instance.
    • Temporarily simplify "Trigger" to True to isolate expression issues.
  • If values change but errors do not clear:
    • Data Rules re-validate fields that now have values after the True Action runs. If an error remains, check the Data Field’s "Is Valid", "Required", "Min Confidence", and other validation settings.

Data Rule properties (overview)

The key Data Rule properties are:

  • "Scope"
  • "Trigger"
    • A Boolean expression. If blank, the rule always executes the True Action.
  • "True Action"
    • The Data Action that runs when the Trigger evaluates to True (or always, if Trigger is blank).
  • "False Action"
    • The Data Action that runs when the Trigger evaluates to False. This is only shown when "Trigger" is not blank.
  • "Required Elements" (obsolete)
    • A legacy way to enforce conditional required elements. Prefer the Require Value Data Action.
  • "Shortcut Keys"
    • Optional shortcut for use in the Data Viewer tab on the Review Page.

Data Actions

Data Actions are the building blocks used in "True Action" and "False Action". Actions can be combined and nested to create multi-step logic.

Below are the main Data Actions, in the order commonly presented.

Calculate Value

Purpose Calculates a value using an expression and applies it to a target field. Use this to standardize computed results (totals, derived values, formatted values) after extraction.

How to configure (step-by-step)

  1. Create/select a Data Rule and set its "Scope" to the container where the target field exists (Data Model, Data Section, or Data Table row context).
  2. For the True Action property, choose Calculate Value.
  3. Set the target field (where the result should be written).
  4. Configure the Calculate Value expression to produce the desired output type (string/number/date depending on the Data Field's "Value Type").

Validation usage Use Calculate Value when you want to enforce a known result:

  • Calculate and set the value (then make the field read-only in the Data Field if it should never be edited), or
  • Calculate and compare to an existing value (for example, flagging mismatches via Raise Issue).


Clear Item

Purpose Clears a value (or clears an item's content) without removing the item from the collection.

Example use cases

  • Clear an invalid value so it must be re-entered.
  • Clear dependent fields when a trigger condition fails.

How to configure (step-by-step)

  1. Create or select a Data Rule.
  2. If desired, set a Trigger using a VB.net expression to identify when the value should be cleared.
  3. Set the True Action property to "Clear Item".
  4. Expand the True Action sub properties.
  5. Select the field(s) or element(s) to clear using the Element property.
  6. Save your changes and test the Data Rule.

Validation usage Clearing values can intentionally force review by triggering required/validation errors on the cleared fields.


Concat

The Concat Data Action merges (concatenates) adjacent records inside a collection—either a multi-instance Data Section or a Data Table. It is used when extraction produces “split” data that should really be treated as one logical record.

In practical terms, Concat looks at the collection from bottom to top and evaluates a Boolean expression ("Trigger") for each pair of neighboring records. When the trigger is True, it merges the “next” record into the “previous” record, then removes the next record from the collection.

Purpose Use Concat to clean up extraction output before validation and export by:

  • Combining “wrapped” or “continued” table rows into a single row.
  • Merging duplicate/fragmented section records that represent one real-world item.
  • Preventing downstream totals, counts, and validations from being wrong due to split records.

What gets merged (behavior) When two records are merged:

  • For simple fields (Data Fields / Data Columns), Concat copies values from the second record into the first only when the first is blank.
  • For child containers:
    • If the child container is a single instance, it recursively fills blanks the same way.
    • If the child container is a collection, it moves the child items from the second record into the first record's collection.
  • After copying/moving, the second record is removed.

This makes Concat a “fill blanks and combine children” merge—not a “overwrite everything” merge.

  • Duplicate records that belong together
    • Symptom: a repeating section is detected twice for the same claim, and one record contains fields missing in the other.
    • Goal: combine them so you get one complete record.
    • Typical trigger idea: merge when key identifiers match between adjacent records.
  • Continuation rows identified by missing key fields
    • Symptom: extracted table creates extra rows where the “Item No” is blank, but descriptive text is present.
    • Goal: merge blank-key rows into the prior row.
    • Typical trigger idea: merge when the next row's key field is blank.

Common Trigger examples Use your own field/code names, but the patterns below illustrate how Concat is designed to work (note the use of the “next record” parameter).

  • Merge when key values match:
 Claim_No = NextItem.Claim_No AND Patient_Name = NextItem.Patient_Name
  • Merge when the next record is missing a key field:
 NOT NextItem.Service_Date
  • Merge when descriptions match:
 Description = NextItem.Description
  • Merge when invoice number matches and next amount is zero:
 Invoice_No = NextItem.Invoice_No AND NextItem.Amount = 0

Step-by-step configuration

  1. Create (or select) a Data Rule.
  2. Set the Data Rule "Scope" to a container that can “see” the collection you want to merge (commonly the Data Model, or the parent Data Section that contains the table/collection).
  3. In the Data Rule "True Action", select Concat.
  4. Configure Concat properties:
    1. Set "Collection" to the target Data Table or multi-instance Data Section you want to process.
    2. Set "Parameter Name" (default is NextItem).
    3. Set "Trigger" to the Boolean expression that decides whether two adjacent records should merge. Use the "Parameter Name" variable to reference fields from the next record (for example NextItem.Amount).
  5. Save changes to the Data Rule.
  6. Test and refine:
    1. Run extraction and review the collection results.
    2. Execute the Data Rule and confirm rows/records merge as expected.
    3. If too many records merge, tighten the "Trigger" (add more conditions).
    4. If too few records merge, loosen the "Trigger" (remove unnecessary conditions) or ensure the correct fields are being referenced.
  7. (Recommended) Add a validation follow-up:
    1. After Concat, use Require Value or Raise Issue rules/actions to enforce that the final merged records contain required values (Qty, Amount, IDs, etc.).

Tips

  • Concat only merges adjacent records. If matching records are separated by another record, they will not merge.
  • Because it processes in reverse order, Concat is well-suited to “continuation row goes into the row above” table cleanup.
  • Keep the "Trigger" specific—overly broad triggers can accidentally merge legitimate rows/records.

Copy

Purpose Copies a value from a source element to a target element.

Example use cases

  • Copy “Invoice Date” into “Posting Date” when posting date is blank.
  • Copy a header field into each table row value if needed.

How to configure (step-by-step)

  1. Create or select a Data Rule.
  2. Set the Data Rule's Scope so the source and target elements are accessible.
  3. Set the True Action to "Copy".
  4. Expand the True Action sub properties.
  5. Set the Source Element property to the Data Element you want to copy.
  6. Set the Target Element property to the Data Element you want to populate with the copied information.

Validation usage Copy can be used to satisfy required fields by ensuring they are populated from a reliable source.


Append

Purpose Appends text (or values) to an existing target field value—useful for building combined strings while retaining what is already there.

Example use cases

  • Append a suffix to an ID.
  • Add a note string when a condition is met.
  • Add information from multi-instances to a single table for easier review.

How to configure (step-by-step)

  1. Create or select a Data Rule.
  2. Set the True Action property to "Append".
  3. Expand the True Action sub properties.
  4. Set the Source Element property to the container element from which you want to append.
  5. Set the Target Element property to the container element where you want the information appended.
  6. Click the ellipsis icon to the right of the Actions property.
  7. When the Actions window appears, click the "+" icon to add an Action. Add as many actions as fields you want to append to.
  8. Configure each action to populate the appended target fields.
  9. Click "OK" when finished.
  10. Save your changes to the Data Rule.
  11. Test your Data Rule.

Validation usage Generally not a validation action. Use Raise Issue or Require Value separately if needed.


Data Lookup

Purpose Runs a Lookup to populate additional values based on existing criteria. This is typically used to enrich data (e.g., vendor info, customer IDs) after extraction.

Example use cases

  • Look up Vendor ID based on Vendor Name.
  • Look up Address details from a Customer Number.

How to configure (step-by-step)

  1. Create/select a Data Rule and set its "Scope" to the container where you will have access to the target field (Data Model, Data Section, or Data Table row context).
  2. For the True Action property, choose Data Lookup.
  3. Expand the sub properties and set the Lookup property for the type of Lookup you will be performing.
  4. Configure the Lookup sub properties the same way you would for a normal lookup.
  5. Add a Trigger and False Action to your Data Rule as desired.
  6. Save your changes and test the Data Rule.

Important behavior note Lookups run by the Data Lookup Data Action can populate Data Elements, but they do not flag individual Data Fields or Data Columns as errors based on lookup miss/conflict settings. If you need “lookup-based validation”, typically:

  • Use Data Lookup to populate, then
  • Use Require Value and/or Raise Issue to enforce the expected result.



Extract From

Extract From is a Data Action that sets a target Data Field's value by running a configured Value Extractor against the value of another (source) Data Field.

Purpose Use Extract From when you already have a “raw” value captured into a field, but you need to:

  • Split a composite value into separate fields (for example, pull a ZIP code out of an address string).
  • Normalize a field by re-extracting only the portion you want to keep.
  • Derive a value from another field without re-running full document extraction (you're extracting from the field's value, not the page).

Extract From is especially useful when it's easier to capture a “big chunk” of text reliably, then parse it into smaller pieces using a pattern/list extractor.

Example use cases

  • Extract Last Name from Full Name
  • Extract Invoice Number from a longer label string
  • Extract a tracking number from a notes/comment field


Step-by-step configuration

  1. Create/select a Data Rule.
  2. Set the Data Rule "Scope" to the container where the fields exist (commonly the Data Model, or a Data Section / Data Table context if the fields are inside a record/row).
  3. Set the True Action property to "Extract From".
  4. Configure the Source Field property to the field that contains the raw/composite text.
  5. Configure the Target Field property to the field you want to populate.
  6. Configure the Extractor property:
    1. Choose an extractor type that can parse the source value (commonly a Pattern Match / regex-based extractor, list match, etc.).
    2. Test the extractor pattern against typical Source Field values to ensure it returns the correct hit.
  7. Set overwrite/miss behavior:
    1. Set "Prevent Overwrite" = True if you do not want to replace existing target values (for example, user-entered corrections).
    2. Set "Ignore Miss" = True if you do not want a failed parse to wipe out the target value.
  8. Test:
    1. Run extraction so the Source Field is populated.
    2. Execute the Data Rule and confirm the Target Field is set correctly.
    3. If the Target Field is an array type, confirm multiple hits combine as expected.

Configuration tips

  • Extract From will not do anything if the Source Field is blank.
  • If "Extractor" is not configured, the action will error at runtime—always set it.
  • Make sure the Data Rule "Scope" matches where the Source/Target fields live (especially for fields inside repeating sections or table rows).


Fill

Purpose Runs fill behavior to populate child elements in a container (commonly used when you want to re-run or apply fill logic after a change).

Example use cases

  • Apply a Fill Method somewhere in a Batch Process other than during Extraction.
  • After setting a key value, run fill logic to populate dependent fields.
  • Apply a Fill Method to a specific section record or table row.

How to configure (step-by-step)

  1. Ensure a Fill Method is already set up and configured on a container Data Element. Ensure the Fill Method has been named.
  2. Set Data Rule "Scope" to the container where the Fill Method is configured (Data Model / Section record / Table row).
  3. If desired, set a Trigger using a VB.net expression.
  4. Set the True Action property to "Fill".
  5. Expand the True Action sub properties.
  6. Set the Fill Method Name property to the named Fill Method previously configured.
  7. Save your changes to the Data Rule and test.

Validation usage Fill itself is not validation. It is often used before Require Value to ensure required data is populated first.


Parse Value

Purpose Parses a value and distributes its parts into other fields (for example, splitting a combined field into separate components).

Example use cases

  • Split “City, ST ZIP” into City / State / ZIP fields.
  • Parse an account string into routing/account components.

How to configure (step-by-step)

  1. Create or select a Data Rule.
  2. Set the Scope property to the appropriate Data Element depending on where your extracted data is located.
  3. Set the True Action to "Parse Value".
  4. (Optional) Set a Trigger if desired using a VB.net expression.
  5. Expand the True Action sub properties.
  6. Set the Source Field property to the Data Element containing the combined value.
  7. Open the Pattern editor by clicking the "..." to the right of the property.
  8. Write a RegEx pattern to return the value you want parsed. Use Capture Groups to determine which part of the pattern should be parsed out to different Data Elements. Name each Capture Group after its target element.
  9. Save your changes to the Data Rule.
  10. Test your Data Rule.

Validation usage Often used to support validation by ensuring each component field is populated and can be validated independently (then use Require Value on the component fields).


Raise Issue

Purpose Creates an issue (a validation/problem report) when a condition is met. Use this to alert users during review or to record a problem for downstream handling.

Example use cases

  • Amount is negative.
  • A required business field is missing under certain conditions.
  • A calculated total does not match the sum of line items.

How to configure (step-by-step)

  1. Set an appropriate "Scope" so the rule runs in the correct context (Data Model, Data Table, or Data Section).
  2. Set "Trigger" to the condition that indicates a problem.
    • Not all Data Actions require a Trigger to work, but the Raise Issue does. It must know when to raise the issue.
  3. Set the "True Action" property to Raise Issue.
  4. Set the message details (issue category/source text if available) on the Log Message property.
  5. Save your changes to the Data Rule and test.

⚠

The Raise Issue Action does not highlight the Data Element with the issue. You will need to be detailed in your Log Message as to indicate where the problem lies.

Validation usage Raise Issue is primarily a validation action. Use it when you need a clear, user-facing indication that something is wrong, without necessarily changing values.


Remove

Purpose Removes data from the target context. Depending on the container, this may remove an item from a collection (such as an instance in a Data Section or a Data Table row) or remove an element instance.

Example use cases

  • Remove table rows that are blank or are header/footer noise.
  • Remove repeated section records that fail a quality threshold.

How to configure (step-by-step)

  1. Set the Data Rule "Scope" to a Data Element that will give you access to the parent Data Element that contains the records or rows that you want removed.
  2. For the "True Action", select Remove.
  3. Expand the sub properties for the True Action.
  4. Set the Collection property to the parent of the records/rows you want removed.
  5. Use a "Trigger" expression to determine when a row/record should be removed (for example, if a key field is blank).
    • The Remove Trigger property is different than the Data Rule Trigger property. The Data Rule Trigger property determines when the whole Data Rule Runs. The Remove Trigger property indicates which records should be removed when the Data Rule is run.
  6. Save your changes to the Data Rule and test.

Validation usage Remove is not a validation action by itself. It is commonly paired with Trigger logic to remove invalid/empty items so they do not cause downstream validation failures.



Require Value

Purpose Enforces that a Data Field (or Data Column) has a value. If it is missing, it is marked as an error and/or an issue is raised depending on the configured behavior.

Example use cases

  • Require “Invoice Number” when “Document Type” is Invoice.
  • Require “Amount” on each line item row.
  • Require a lookup-populated field after a Data Lookup action.

How to configure (step-by-step)

  1. Set "Scope" so the required field exists within the active instance (document/record/row).
  2. In "True Action", select Require Value.
  3. Expand the True Action sub properties and use the Required Elements property to choose the field(s) to require.
  4. (Optional) Provide a rule-specific message context (for example, include the rule name or field path) in the Log Message property.
  5. Save your changes and test your Data rule.



Run Command

Purpose Runs a command as part of rule execution. Use this when you need to run an existing Grooper command against the current context as part of normalization.

Example use cases

  • Run a utility command that updates values or performs a specialized operation already available as a command.

How to configure (step-by-step)

  1. Choose Run Command as the Data Rule's "True Action".
  2. Expand the True Action sub properties.
  3. Select the Data Element where you want to run the command in the Element property.
  4. Set the Command property to the command you want to run.
  5. Save your changes to the Data Rule.
  6. Test your Data Rule.

⚠

The commands you can run depend on your Scope and Element selections. You can run some commands on a Data Model that you can't run on a Data Section or Data Table.


Action List

Action List is a Data Action that contains an ordered list of other Data Actions and runs them in sequence as a single unit.

In a Data Rule, you typically assign one action to "True Action" (and optionally one action to "False Action"). Action List is how you run multiple steps when a rule fires.

Purpose Use Action List to build a clear, repeatable “pipeline” of normalization steps, such as:

  • Fix/standardize values first (Calculate Value, Extract From, Parse Value, Copy, Concat, etc.).
  • Then enrich (Data Lookup, Fill, Run Command).
  • Then validate (Require Value, Raise Issue).
  • Optionally, finalize cleanup (Clear Item, Remove).

This keeps a single Data Rule readable (one trigger, one “bundle of steps”) and avoids needing many small rules just to run multiple actions.

Examples (when to use it)

  • Normalize then validate
    • Step 1: Extract a clean Invoice Number out of a label field (Extract From).
    • Step 2: Copy it into another field used for export (Copy).
    • Step 3: Require the export field (Require Value) or raise an issue if missing.
  • Table cleanup workflow
    • Step 1: Concat to merge continuation rows.
    • Step 2: Remove rows that are now empty/noise.
    • Step 3: Require Value on key columns like Quantity and Amount.
  • Field cleanup + formatting
    • Step 1: Parse Value to split “City, ST ZIP”.
    • Step 2: Calculate Value to normalize/format one of the parts.
    • Step 3: Require Value on the split fields.

How it behaves (important notes)

  • Actions run in the order they appear in the list.
  • If later actions depend on earlier actions (for example, Require Value depends on Data Lookup), put them in that order.
  • Action List itself is not “validation”; it's a container. Validation behavior comes from what actions you include (Require Value, Raise Issue, etc.).

Step-by-step configuration

  1. Create/select a Data Rule.
  2. Set the Data Rule "Scope" to the correct container (the context where the actions should operate): Data Model, Data Section, or Data Table.
  3. (Optional) Set "Trigger" if the steps should only run under certain conditions.
  4. Set the rule's "True Action" to Action List.
  5. Configure the Action List:
    1. In the Action List, add Data Actions in the order you want them to run.
    2. Configure each action's key properties (for example "Source Field", "Target Field", "Collection", "Extractor", etc.).
  6. Test the sequence:
    1. Run extraction so you have real values to operate on.
    2. Execute the Data Rule (or run it during Review if applicable).
    3. Confirm each step's output before moving on to the next (especially for lookups and parsing).
  7. (Optional) Add a "False Action" on the Data Rule if you need “else” behavior when the trigger is False (for example, Clear Item or Raise Issue).

Practical tips

  • Keep Action Lists short and focused; use multiple rules (or child rules) when there are distinct decision points.
  • When troubleshooting, temporarily disable later actions (or move them out) to confirm earlier steps are behaving as expected.
  • If you need a multi-branch workflow (if/else-if style), prefer using Data Rule Trigger logic with child Data Rules rather than one very large action list.


Execute Rule

Execute Rule is a Data Action that runs another Data Rule as part of the current rule's action sequence.

This lets you “call” a separate rule from inside a parent rule, so you can reuse the same rule logic in multiple places instead of duplicating actions.

Purpose Use Execute Rule to:

  • Modularize complex logic into smaller, easier-to-maintain rules.
  • Reuse the same normalization/validation logic across multiple parent rules.
  • Keep a parent rule readable by pushing detailed steps into a “helper” rule.

Important scope requirement The rule you execute must apply to:

  • the same element as the current rule's scope, or
  • a descendant of that scope (for example, a rule scoped to a Data Table can be executed from a rule scoped to the Data Model, as long as it is in that Data Model tree).

If the selected rule does not apply to the current target scope (or a descendant), the Execute Rule action will not run it.

Examples (when to use it)

  • Shared “Normalize vendor” logic
    • You have a standard set of steps to clean Vendor Name, run a lookup, and require Vendor ID.
    • Put that logic in one rule (for example, “Normalize Vendor”).
    • Use Execute Rule from multiple parent rules (different document types or different trigger conditions) to apply the same vendor logic consistently.
  • Standard “Line item cleanup” used across invoices
    • Create a rule scoped to the Line Items Data Table that:
      1. merges continuation rows (Concat),
      2. removes empty rows (Remove),
      3. requires key columns (Require Value).
    • In each invoice-type rule, use Execute Rule to run the shared Line Items cleanup rule.
  • Multi-stage processing
    • Parent rule decides “when” to run something (Trigger).
    • Execute Rule runs the full block of steps only when needed (instead of embedding a long Action List in every branch).

Step-by-step configuration

  1. Create/select the “child” rule you want to reuse (the rule that will be executed):
    1. Create a Data Rule with the appropriate "Scope" (Data Model, Data Section, or Data Table).
    2. Configure its "Trigger" (optional) and "True Action" logic.
    3. Save it in an appropriate Resource Folder so it is available where you need it (typically a local Resource Folder on the Content Type or inherited from the Content Model).
  2. Create/select the “parent” rule (the one that will call the child rule).
  3. Set the parent rule’s "Scope" to the container where you want the overall logic to run.
  4. In the parent rule’s "True Action" (or inside an Action List), choose Execute Rule.
  5. Set the Execute Rule action’s "Rule" property to the child rule you created.
  6. Test:
    1. Use the Data Rule Tester tab to run the parent rule.
    2. Confirm the child rule executes (and that its changes/issues appear as part of the parent rule results).
    3. If it does not execute, verify the child rule’s "Scope" applies to the parent scope (or a descendant) and that the child rule is accessible from the available Resource Folders.

Troubleshooting tips

  • If the rule won't select in the picker (or doesn't show up), it is usually not in a Resource Folder that is in-scope.
  • If the action runs but nothing changes, confirm:
    • the executed rule's "Trigger" evaluates to True (or is blank), and
    • the executed rule is scoped correctly for the instance it is being run against.

Retrieved from "https://wiki.grooper.com/index.php?title=Data_Rule_(Node_Type)&oldid=32881"