5.4 Cross-Entity Rules, Rule Context, and Rule Design Practices

5.4 Cross-Entity Rules, Rule Context, and Rule Design Practices

Quick Answer: A cross-entity rule is triggered in a source entity (its base object) and changes a target entity. For example, a Job Information change can add an HR manager in Job Relationships. Only six employment entities are supported, with at most five cross-entity rule scenarios per entity. Rule context lets you switch a rule off for specific situations, such as mass changes, for onSave and onChange rules on HRIS elements.

Cross-Entity Rules

Cross-entity rules set values in a different entity from the one that triggered them. Supported entities:

• Job Information
• Job Relationship Information
• Compensation Information
• Recurring Pay Component
• Non-Recurring Pay Component
• Employment Information

Direction matters: the source element must be the base object of the rule. Common use cases:

Event Support and Limits

• The History UI and imports support only onSave rules for cross-entity scenarios.
• onChange cross-entity rules generally work only when both entities are displayed on the UI, as in the Manager Self-Service screen.
• There can be a maximum of five cross-entity rule scenarios for an HRIS entity.

Worked Example from THR81

ACE Corporation wants Nancy Nash added automatically as the HR Manager for employees in legal entity Ace USA and business unit Corporate Industries.

To test, change the employee's department through Change Job and Compensation Info, submit, and approve the workflow steps by proxy. After final approval, a new Job Relationships entry for Nancy Nash appears. SAP suggests two ways to skip approvals during testing: temporarily disable the workflow rule in BCUI, or use the Job Information History with the Transfer event and Department Change reason.

Rule Context

Rule context narrows the situations in which a rule runs. The classic case: you do not want a workflow derivation rule to fire during a mass change, which could launch one workflow per employee.

• Rule context applies to onSave and onChange rules only.
• It applies to HRIS elements only, not MDF objects.
• Every context defaults to Yes. Set a context to No to stop the rule in that situation.

This matters for Mass Data Management. SAP notes that it triggers all onSave and PostSave rules. If you do not want onSave rules such as workflow derivation to run, set the rule context for mass changes to No in Manage Business Configuration (Section 8.3).

Rule Design Practices

SAP's EC lessons repeat several design rules:

• Fewer onSave rules perform better. Group related logic, such as all event reason derivation conditions, into one rule with several IF/ELSE IF branches where maintainability allows.
• Split rules only when needed, for example when requirements are complex or change frequently. Splitting may cost some performance.
• Rule IDs without spaces. SAP warns that ERD rules with spaces in the ID don't trigger correctly.
• Always cover the fallback. For event reason derivation, add a catch-all ELSE or a final rule, otherwise users see "Unable to determine the event reason for the proposed changes" (Section 9.4).
• Assign with the correct base object and event. A rule built on a Model base object must be assigned with that Model base object.
• Order element-level rules deliberately in BCUI. The platform still runs ERD and workflow derivation last.
• Remember scope: EC Quick Actions run rules assigned onSave, onChange, onView, and onPostSave for all fields, even fields not included in the template (Section 10.1).
• Migrate Basic rules to application-specific scenarios. They are easier to build and less error-prone, and the Check Tool offers a migration check.

Choosing the Right Rule Mechanism

Exam Tip

When a practical task says "when X changes, Y in another block must update", check first whether both blocks are among the six supported entities. Then check whether the change will be made through a UI that shows both entities (onChange works) or through History or an import (onSave is required).