Talk:Data Rule (Node Type)

Randall Kinard 2026-04-21

What’s Good

• Clear, accurate introduction
  • Does a great job explaining what a Data Rule is and how it differs from extractors
  • The “finding vs fixing data” distinction is especially useful

• Strong explanation of Scope (major strength)
  • Clearly explains how rules run at:
    • Data Model level
    • Data Section level
    • Data Table row level
  • This is critical to understanding Data Rules and is handled well

• Good breakdown of Trigger / True / False logic
  • Easy to follow and logically structured
  • Explains execution flow clearly, including child rule behavior

• Helpful conceptual positioning
  • Differentiates Data Rules from:
    • Extractors
    • Batch Process logic
  • Reinforces that Data Rules operate inside the Data Model

• Practical configuration steps
  • Step-by-step setup is clear and usable
  • Includes optional elements (Trigger, False Action, Shortcut Keys) without overwhelming

• Nice inclusion of testing/troubleshooting tips
  • Covers real-world issues:
    • Rule not appearing
    • Trigger not firing
    • Errors not clearing
  • This is very useful and something we could probably do more of

• Good structure and readability so far
  • Flows logically from concept to configuration to usage
  • Easy to follow for intermediate users

What Could Be Improved

• This is obviously still an article in progress.

• Lacks a quick “what should I use this for?” summary
  • Good explanations exist, but no quick guidance
  • Suggestion:
    • Add a short section like:
    • “Use Data Rules when…”
      • You need if/then logic
      • You’re working across multiple fields
      • You need row/section-level logic

RPatton Response: Added an area that gives examples of when to use Data Rules.

• Could use a simple example early on
  • Maybe a simple use case would help?
  • Suggestion:
    • Add a quick example near the top:
      • “If Payment Type = PO → require PO Number”

RPatton Response: Added.

• Data Actions section could use stronger framing
  • Suggestion:
    • Flesh out a stronger explanation of what the Actions are and what they're for

RPatton Response: Done

• Minor redundancy and wording tightness
  • A few areas repeat similar ideas (especially around Trigger behavior)
  • Some sentences could be slightly tighter
  • Suggestion:
    • Light editing pass to streamline phrasing

RPatton Response: Done

• Perhaps it's coming eventually, but a tie in to validation might help?

RPatton Response: Added a validation section.

Randall Kinard 2026-05-15

Extract From

What’s good

• Very clear explanation of the action’s purpose and where it fits in the workflow.
• The “raw field → usable field” explanation is excellent and easy to understand.
• Good practical examples (ZIP from address, invoice number from larger text, etc.).
• Strong configuration guidance, especially around:
  • Prevent Overwrite
  • Ignore Miss
  • Scope considerations
• The validation section explains *why* this action matters instead of just what it does.

What could be improved

• The distinction between Extract From and Parse Value could be sharper.
  • Right now they feel conceptually close.
  • A quick “Use Extract From when...” vs “Use Parse Value when...” comparison would help.
• Could use one more realistic business example:
  • “Extract PO Number from freeform notes”
  • “Extract tracking number from email body text”

Execute Rule

What’s good

• One of the strongest conceptual sections in the article.
• The idea of reusable “validation modules” is explained very naturally.
• Excellent real-world examples:
  • Shared vendor normalization
  • Shared line-item cleanup
  • Multi-stage workflows
• Scope limitations are explained clearly without becoming overly technical.
• Strong maintainability angle—this section communicates *why* modular rules matter.

What could be improved

• Could benefit from one short warning about:
  • accidental recursion / circular rule execution
  • overly deep nesting becoming hard to troubleshoot
• A small visual example of:
  • Parent Rule → Execute Rule → Child Rule

would make the concept even easier to grasp quickly.

Action List

What’s good

• Excellent explanation of Action List as a “pipeline” rather than just a container.
• The sequential workflow examples are very practical and realistic.
• Good emphasis on execution order and dependency between actions.
• The validation explanation is especially strong:
  • normalize → enrich → validate

This communicates real-world rule design very well.

What could be improved

• Some overlap now exists between:
  • Action List
  • Execute Rule

Both are about organizing multi-step logic.

• A brief clarification would help:
  • Action List = inline sequence
  • Execute Rule = reusable external sequence
• The section is conceptually strong, but slightly wordy in places.

Validation with Data Rules

What’s good

• This section significantly improves the article overall.
• Finally ties all the Data Actions together into a coherent validation strategy.
• The validation patterns are excellent:
  • Conditional required fields
  • Cross-field checks
  • Lookup validation
  • Row-level validation
• Very practical and grounded in real Grooper use cases.
• The Scope guidance at the end is concise and genuinely helpful.
• The article now feels much more complete because of this section.

What could be improved

• The opening statement is accurate, but slightly confusing:
  • “Data Rules themselves do not perform validation...”
• Technically true, but some actions absolutely *do* directly validate.
• Consider tightening this to something like:
  • “Data Rules orchestrate validation logic, while specific Data Actions perform the actual enforcement.”
• The numbered patterns are strong, but would benefit from:
  • a small summary table
  • or quick “best tool for this scenario” guidance
• Could also briefly mention:
  • “hard validation” vs “soft validation”
  • (Require Value vs Raise Issue)

Overall impression of the new additions

The new additions make the article feel much more mature and cohesive. Earlier versions explained Data Actions individually; these newer sections start explaining how people actually design rule systems in Grooper.

The article is increasingly becoming less of a property reference and more of a true implementation guide—which is a very good direction.