ContextResolver Identity.Read values not working in EnsureOutOfOffice template substitution

[ntt-matthias-fleschuetz]

Description

Using the values from Request.Context.Identity.Profile.* in template substitution with EnsureOutOfOffice and EXO provider doesn't work and brings an error on plan creation.

Steps to Reproduce

1. Step with

@{
            Name = 'EXO - Set OOO message'
            Type = 'IdLE.Step.Mailbox.EnsureOutOfOffice'
            With = @{
                IdentityKey = '{{Request.IdentityKeys.sAMAccountName}}@nanotempertech.com'
                Provider = 'EXO'
                AuthSessionName = 'EXO'
                Config = @{
                    Mode = 'Enabled'
                    InternalMessage = 'Dear Sender,<br/>{{Request.Context.Identity.Profile.DisplayName}} is not working at NanoTemper anymore.<br/>Your email is not forwarded and will be deleted automatically, due to legal compliance.<br/>For further contact please mail to: {{Request.Context.Manager}}. <br/>Best, <br/> NanoTemper Technologies'
                    ExternalMessage =  'Dear Sender,<br/>{{Request.Context.Identity.Profile.DisplayName}} is not working at NanoTemper anymore.<br/>Your email is not forwarded and will be deleted automatically, due to legal compliance.<br/>For further contact please mail to: {{Request.Context.Manager}}. <br/>Best, <br/> NanoTemper Technologies'
                    ExternalAudience = 'All'
                    MessageFormat = 'HTML'
                }
            }
        }

2. Run plan after initializing $providers, $workflowfile and $request properly

$plan = New-IdlePlan -WorkflowPath $workflowFile -Request $request -Providers $providers

Expected Behavior

Being able to resolve this path from Context and substitute in Message for OutOfOffice.

Actual Behavior

Error on plan

Line | 
 115 |              throw [System.ArgumentException]::new(
     |              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | Template resolution error in step 'EXO - Set OOO message': Path 'Request.Context.Identity.Profile.DisplayName'        
     | resolved to null or does not exist. Ensure the request contains all required values. (Parameter 'Workflow')

Additional Context

Without error step I can see the values for the EnsureOutOfOffice Message clearly in the profile:

{ 
  "IdentityKey": "max.power",
  "Enabled": false,
  "Attributes": {
    "Title": "High Performer",
    "Surname": "Power",
    "DistinguishedName": "CN=Max Power,OU=some,OU=Folder,DC=corp,DC=domain,DC=tld",
    "DisplayName": "Max Power",
    "Description": "OFFBOARDING Stage I - 2026-02-30",
    "Department": "High Performance IT",
    "GivenName": "Max",
    "UserPrincipalName": "max.power@domain.tld",
    "EmailAddress": "max.power@domain.tld",
    "sAMAccountName": "max.power"
  }
}

Environment

• PowerShell version: 7.5.4
• OS: Windows Server 2019
• IdLE version / commit: main
• Execution context (CLI / Service / CI): CLI

[blindzero]

I rechecked this issue against the current main branch and the recently merged ContextResolver redesign.

The original issue was valid: Request.Context.Identity.Profile.DisplayName failed during template substitution at plan creation time, although the underlying resolver output existed. (github.com)

At the time, PR #258 tried to solve this by flattening Identity.Profile.Attributes.* into direct Identity.Profile.* access and removing the nested Attributes container entirely as a breaking change. (github.com)

That is no longer the correct target state. PR #259 has now been merged and introduces the new ContextResolver architecture based on provider/auth-scoped source-of-truth paths, deterministic Views, and Request.Context.Current for step-relative evaluation. (github.com)

With that change in place, the right resolution for #254 is not to merge the flattening approach from #258. The remaining work is to make sure docs, examples, troubleshooting guidance, and tests consistently reflect the new model and no stale flattening assumptions remain. The review notes in #259 explicitly identify this follow-up, including correcting examples that still imply ...Identity.Profile.DisplayName when the actual profile attributes are under ...Identity.Profile.Attributes.<Name>. (github.com)

I therefore suggest treating #254 as functionally superseded by #259 from an architectural perspective, and tracking the remaining cleanup in a separate focused follow-up issue.