3771071 - Custom Determination for Case Object Is Not Triggered, or Does Not Retain Its Value, When an Extension Field Is Null or Updated by Multiple Determinations

• A custom determination configured on the Case business object does not execute, or does not retain its result, even though all expected business conditions appear to be met.
• The following two patterns describe hypothetical scenarios in which this symptom can occur, based on common determination configurations. A given case may exhibit one or both, depending on how the determinations are set up:
  • Pattern A – Field never updates:
    • An inbound email is linked to an existing case.
    • The Last Customer Interaction On time point is updated successfully.
    • A determination is expected to set a custom extension field from false to true.
    • The determination is not executed, and the extension field remains unchanged.
  • Pattern B – Field updates and then immediately reverts:
    • An inbound email is linked to an existing case and all conditions are met.
    • A determination correctly sets the custom extension field to true.
    • A second determination, intended to reset the field under different circumstances, also evaluates as true in the same transaction and immediately reverts the field back to false.
    • When the case is checked afterward (for example via API or UI), the field appears as though it was never updated at all, even though it changed value twice within the same transaction.

• SAP Service Cloud Version 2 1.0
• SAP Sales Cloud Version 2 1.0

• Hypothetical Scenario – Updating an Extension Field via Determination
  The scenario below illustrates a common pattern: a business wants to update a custom extension field, for example {extensions/XYZ}, to true whenever a customer sends a new inbound email on an existing case, based on specific criteria defined in a determination.
  • 1. A case already exists, with {extensions/XYZ} = false (or null, if not yet initialized).
    2. The customer sends a new inbound email related to the case.
    3. During Standard Determinations, the email is classified as customer-initiated and Last Customer Interaction On is updated and committed.
       
  • Pattern A:
    • Ensure a case already exists.
    • Send another customer email related to the same case (email-to-case update).
    • Observe that the Last Customer Interaction On field updates after a short delay, indicating the inbound email was processed.
    • Ensure all conditions in the PostHook determination responsible for setting the extension field are met.
    • Observe that the extension field remains false and is not updated.
  • Pattern B:
    • Ensure a case already exists, with two PostHook determinations configured on the same extension field — one that sets the field to true, and another that is intended to reset it to false under different conditions.
    • Send a customer email related to the same case so that all conditions for the first determination are met.
    • Check the case change history (not just the final field value) and confirm whether the extension field was set to true and then reset to false within the same save transaction.
    • Observe that the field shows false when checked after the transaction completes, even though it was briefly true during processing.

• Cause 1 – Null vs. False condition mismatch (Pattern A)
  • • The determination condition checks whether a custom extension field equals false.
    • Example: extensions/YY1_EmailReceived = False
      • If the extension field has not been initialized during record creation, its value may be null instead of false.
      • Since null and false are treated as different values, the condition is not fulfilled and the determination is not executed.
      • Subsequent determinations that depend on the field being set to true are also not triggered.
        
• Cause 2 – Conflicting PostHook determinations within the same transaction (Pattern B)
  • • PostHook determinations on the same business object execute sequentially within a single save transaction, in the order they are configured.
    • If a second determination evaluates the current (in-transaction) value of a field that was just set by an earlier determination in the same transaction, it may unintentionally treat that newly-set value as if it were the pre-existing value.
    • Example:
      • Determination A sets extensions/YY1_EmailReceived = True.
      • Determination B, configured to trigger when extensions/YY1_EmailReceived = True under different circumstances, also evaluates as true immediately afterward and resets the field to False, all within the same transaction.
    • As a result, the field is set and then immediately reverted before the transaction completes, so any check performed after the save (UI, API, or otherwise) shows the reverted value, masking the fact that the field briefly changed.
    • This is distinct from Cause 1: the determinations are executing correctly and the PostHook framework is firing at the correct point in the save sequence (after standard determinations have updated time point fields such as Last Customer Interaction On). The root cause is the condition logic not distinguishing between a value that existed before the transaction and a value that was only just set during the same transaction.

Background – Case Save Execution Sequence:

When a Case business object is saved, processing occurs in a fixed sequence:

1. Custom Pre-Hook – custom logic executed before standard system processing.
2. Standard Determinations – system-delivered logic, including evaluation and update of standard time point fields such as Last Customer Interaction On, based on the inbound email and party data.
3. Custom Post-Hook – custom determinations configured by the customer, executed after standard determinations have completed and committed their updates within the same transaction.

Because standard time point fields are updated during the Standard Determinations phase, their updated values are already available by the time Custom Post-Hook determinations evaluate their conditions. This confirms that, from a sequencing perspective, a Custom Post-Hook determination can reliably read an updated time point field such as Last Customer Interaction On within the same transaction in which the inbound email was processed.

Last Customer Interaction On update logic (Email-to-Case):

• On Case creation: the Last Customer Interaction On field is set.
• On a subsequent inbound email (Email-to-Case update): if the sender is not part of the case’s employee parties, the interaction is treated as customer-initiated and the time point is updated. If the sender is recognized as an employee party but is also linked to the case in an employee role, the interaction may still be treated as customer-initiated and the time point updated; otherwise, it is treated as agent-initiated and the time point is not updated.

This distinction matters because not every inbound email updates Last Customer Interaction On — only those classified as customer-initiated do. A determination relying on this field as a trigger should account for this when reviewing why an expected update did not occur.

For Cause 1 (null vs. false):

• Review the determination conditions and ensure that null values are handled explicitly.
• Initialize the extension field during record creation where possible.
• Alternatively, modify the determination logic to account for both null and false values, for example using “Is not equal to True” rather than “Equals False”, or by adding an explicit OR condition block that checks for null.
• Example scenario:

• Determination A: LastCustomerInteractionOn is not null AND CustomField = False
• If CustomField is null, the determination will not execute, since null and false are not equal.

• The condition should be adjusted to handle records where the field has not yet been initialized.

For Cause 2 (conflicting determinations):

• Identify all PostHook determinations that read or write the same extension field, and review the order in which they execute.
• Use the Previous Value option available on the condition row for the affected field, where supported. This allows a determination to compare the field’s value before the current transaction against its value during or after the transaction, rather than only evaluating the current in-transaction state.
• This distinguishes a field that was already true coming into the transaction from a field that was only just set to true by an earlier determination within the same transaction, preventing the second determination from incorrectly reverting it.
• As a diagnostic step, temporarily disabling one of the conflicting determinations and retesting can help confirm whether sequential determination conflict is the cause before making permanent changes.
• After updating the determination logic, retest the full scenario end to end and verify the extension field retains the expected value after the transaction completes.

Additional Notes:

• • The update of the Last Customer Interaction On field confirms successful inbound email processing and is independent of custom determination execution.
  • PostHook determinations execute after standard determinations have updated system time point fields, so values such as Last Customer Interaction On are already committed and available when PostHook conditions are evaluated.
  • When troubleshooting a custom field that appears not to update, review the case change history rather than only the final field value, as this can reveal whether the field changed and was subsequently reverted within the same transaction (Pattern B) versus never changing at all (Pattern A).
  • This is a consulting/configuration topic related to custom determination design rather than a product defect; the underlying PostHook execution sequence is working as designed in both patterns described above.

determination, posthook, extension field, email-to-case, last customer interaction on, timePoints, adminData, null value, boolean false, case update, custom field, where-used, service cloud v2, case determination , KBA , CEC-CRM-CAS , Case Management for SAP Sales/Service Cloud , Problem