Simple Object Designer Documentation
Index

Advanced Rules

This page covers advanced scenarios for mandatory field rules, including field-to-field comparisons, working with document headers and lines, and complex validation patterns.

Field-to-Field Comparison

Instead of comparing to a fixed value, put another field's reference into the Expression (Right side) value.

Setting Up Field Comparison

  1. Create a new condition
  2. Select the first field in the Field lookup
  3. Choose the operator
  4. In Expression (Right side), type a record-field reference such as Rec."Order Date"

Example: Date Validation

Ensure promised delivery date is after order date:

Field: Promised Delivery Date
Operator: >=
Expression (Right side): Rec."Order Date"

Example: Amount Validation

Ensure line discount doesn't exceed item's maximum:

Field: Line Discount %
Operator: <=
Expression (Right side): Rec."Maximum Line Discount"

Header/Line Document Rules

For documents with headers and lines (Sales Order, Purchase Order, etc.), a single rule can validate against either level by setting Field Location.

Field Location

Value Meaning
Main Table Field on the page's source record (Rec.)
Sub Table Field on the lines record (Lines.)

When the rule lives on a document header, choosing Sub Table lets you reference the lines record (Lines."Quantity", etc.) in the right-side expression.

Rules for Custom Fields

Mandatory rules work on both system fields and SOD custom fields.

Custom Field Rules

After creating a custom field with SOD:

  1. Place the field on a page
  2. Navigate to Mandatory Fields for that page
  3. Find your action
  4. Add a condition for your custom field

Example: Custom Reference Required

Custom field "External Reference" on Sales Order:

Page: Sales Order
Action: Release
Field: External Reference (your custom field)
Operator: <>
Expression (Right side): ''

Conditional Business Logic

While SOD rules are straightforward comparisons, you can achieve conditional-like behavior through rule design.

Status-Based Requirements

Different requirements based on document status:

Scenario: Require Ship-to Address only when Status = "Released"

Approach:

  • For basic cases, use the status check in your rule
  • This requires the action to only be available in certain statuses

Amount Thresholds

Different validation based on amounts:

Scenario: Large orders require additional approval fields

Rule 1: Amount > 10000 implies Approval Code not blank

Note: SOD rules evaluate independently, so complex conditional logic may require custom development.

Compound Conditions (AND across several fields)

Making a field mandatory only when two or more other conditions are simultaneously true is a supported scenario:

IF Field A = value1 AND Field B = value2 THEN Field C is mandatory

Worked example (generalised): on a Purchase Order Lines action such as "Request Approval", require a custom field only when Type = 'GL Account' and No. = '<a specific account number>'.

Configure the two triggering conditions at the same level, with the target mandatory field nested beneath them. That structure is the intended and supported approach for AND logic.

Dimensions in conditions

Only Global Dimension 1, Global Dimension 2 and Dimension Set ID are available as condition fields. Other, non-global dimensions cannot be referenced, because of the way dimensions are constructed in Business Central, and there is currently no workaround inside SOD. See Limitations.

Multiple Page Coverage

The same business rule may need implementation on multiple pages.

A sales order might appear on:

  • Sales Order page
  • Sales Order List
  • Sales Orders by Customer
  • Mini Sales Order

Implementing Across Pages

  1. Identify all pages showing the same table
  2. Add rules to each relevant page
  3. Maintain consistency across pages

Example: Customer Name Required Everywhere

Page Action Field Rule
Sales Order Release Sell-to Customer Name <> ''
Sales Quote Make Order Sell-to Customer Name <> ''
Sales Invoice Post Sell-to Customer Name <> ''

Testing Strategy

Create Test Scenarios

Scenario Field Value Expected Result
Empty required field (blank) Block action, show error
Valid value "Customer ABC" Allow action
Boundary value 0 Depends on rule (>0 blocks)
Edge case Whitespace only May pass "Not Blank"

Test Each Rule

For actions with multiple rules:

  1. Fail first rule only
  2. Fail second rule only
  3. Fail all rules
  4. Pass all rules

Document Test Results

Keep records of:

  • Test date
  • Scenarios tested
  • Results
  • Any issues found

Troubleshooting Rules

Rule Not Blocking

Possible causes:

  • Extension not published
  • Wrong page targeted
  • Wrong action selected
  • Rule configured incorrectly

Solutions:

  • Verify extension is published
  • Confirm page and action names
  • Review rule configuration

Compound Condition Field Shows in Red / Not Accepted

Symptom: while configuring a compound condition, the target field displays in red and SOD will not accept the configuration.

First step: update to the latest SOD version. A recent bug affected compound-condition mandatory fields, and the fix ships in the current release.

If the field still shows red on the latest version, send the app file to support@hougaard.com for direct review.

Wrong Error Message

Possible causes:

  • Multiple rules, showing different message
  • Field caption unclear

Solutions:

  • Review all rules on the action
  • Improve field captions

Rule Too Restrictive

Possible causes:

  • Operator too strict
  • Right-side expression incorrect
  • Business requirement misunderstood

Solutions:

  • Review business requirement
  • Adjust operator or right-side value
  • Consider if rule is necessary

Rule Not Strict Enough

Possible causes:

  • <> '' accepting whitespace
  • Numeric comparison not catching edge cases
  • Right-side value too permissive

Solutions:

  • Review edge cases
  • Use Text Length > for stricter non-empty checks
  • Add additional rules

Best Practices for Advanced Rules

Keep Rules Maintainable

  • Document the business reason for each rule
  • Use consistent patterns
  • Group related rules logically

Consider User Experience

  • Don't over-validate
  • Provide clear error messages
  • Balance data quality with usability

Plan for Changes

  • Business rules evolve
  • Make rules easy to modify
  • Test thoroughly after changes

Coordinate with Business

  • Validate rules with business users
  • Get sign-off on requirements
  • Review rules periodically

Limitations

What SOD Rules Cannot Do

  • Complex multi-field logic (A AND B implies C)
  • Database lookups during validation
  • External API calls
  • Workflows or approvals

When to Use Custom Development

If you need:

  • Complex conditional logic
  • Cross-table validation
  • Integration with external systems
  • Workflow routing

Consider custom AL development instead of SOD rules.