Automations Do Not Provide Nested Property Objects in Newly Created Entities to Workflows

[LaceyGilliam]

Description

When an automation is configured to start a workflow when a new record is created, the newly-created and primitive property values are available to the Entity passed to the workflow. However many nested property objects are null. Some research with Claude suggests that this is because the workflow is passed the in-memory entity object that was just created rather than re-querying the database like the Workflow Triggers used to do.

For example, we configured an Automation to run when FinancialTransactionDetail records are created. The workflow is able to use Set Attribute from Entity to access {{ Entity.Amount }} and {{ Entity.Transaction }} properties since those were just set as part of the record creation, but using the template {{ Entity.Account.Name }} results in null since the account wasn’t just created (note: {{ Entity.AccountId }} does work since that primitive was just set as part of the record creation).

(Unverified) Claude Notes:

---

The Automation's "Entity Change" trigger hands the workflow the exact same in-memory entity object that was just saved — it does not re-query the database. See EntityChangeMonitor.cs:204-214:

var request = new AutomationRequest
{
    Values = new Dictionary<string, object>
    {
        [AutomationRequest.KnownKeys.Entity] = entry.Entity,   // <-- the live save entry, not a fresh query
        ...
    }
};

This is called from DbContext.cs:887, inside the post-commit callback, still passing around the same item.Entity reference used for the SaveChanges() call — not a re-fetched copy. (Contrast this with the legacy WorkflowTrigger/PostAdd/PostSave path in ProcessWorkflowTrigger.cs:72, which explicitly re-loads the entity from the database via EntityTypeService.GetEntity() before running the workflow — that path doesn't have this problem.)

Because you get the literal object that was being inserted, any navigation property the save code never explicitly populated will be null, even though its FK column landed in the database fine.

Actual Behavior

Trying to look up properties from already-existing nested property entities such as {{ Entity.Account.Name }} results in null, even though new values and primitive properties are available (such as {{ Entity.AccountId }}).

Expected Behavior

{{ Entity.Account.Name }} should have stored something like “General Fund” in the workflow attribute, since the Account was properly set on the TransactionDetail record.

Steps to Reproduce

1. In the internal Rock site, create a new Workflow type at Admin Tools > Settings > Workflow Configuration.
2. Configure the workflow with two text attributes: AccountId and AccountName.
3. Add two Set Attribute From Entity actions, both set to “Show in Grid” for easy review.
       1. The first will set AccountId using the template {{ Entity.AccountId }}.
       2. The second will set AccountName using the template {{ Entity.Account.Name }}.
     

4. Set the workflow to automatically persist so we can see the results after the automation runs, then Save.
5. Now create a new Automation at Admin Tools > Settings > Automations.
6. Choose Trigger Type: Entity Change, Entity Type: Financial Transaction Detail, and Trigger on: Added.

7. Save and then add an event to Launch Workflow. Choose the workflow type that you just created.

8. Finally, add a Financial Transaction (the easiest method is from someone’s profile > contributions tab) which should launch the workflow.

9. Check the persisted workflow to see what values were available to the workflow.

Issue Confirmation

• Perform a search on the Github Issues to see if your bug is already reported.
• Reproduced the problem on a fresh install or on the demo site.

Rock Version

At least v18.1 through Pre-Alpha 20.0.5

Client Culture Setting

EN-US

[cabal95]

@LaceyGilliam Thanks for the reproduction steps. The Launch Workflow automation will now reload the entity from the database so that navigation properties (like Account) work correctly.