The short answer is that Evaluation Code cannot access a Worklet's payload, but it can run code, including code that changes the device. Those two points are often conflated, so they are worth separating.
The payload is not available to Evaluation Code
Files attached to a Worklet as a payload are staged for the remediation execution. They are not present when the Evaluation Code runs, so an evaluation that references the payload will not find it.
Design the evaluation around what is already on the device instead. Check for the presence of a file, a registry value, an installed application, a service state, or a version number, and let the remediation be the part that consumes the payload.
When the remediation does run, the payload is staged into a working directory created for that execution, and the directory name is generated per run. Do not hardcode an absolute path to it. Reference the payload by its filename relative to the working directory, which is what the catalog Worklets that use payloads do.
Evaluation Code does run, and it can change things
Evaluation Code is a real script executed on the device, with the same privileges as the remediation. There are no guardrails preventing it from modifying the device. That is a responsibility rather than a feature: an evaluation that makes changes will make them on every device scan, because evaluation runs on each scan whether or not the policy has a schedule.
Keep evaluations read-only. See Can a Worklet's Evaluation Code make changes to a Device?
Keep evaluations fast and self-contained
Because evaluation runs on every scan across every assigned device, anything slow or unreliable in it is repeated constantly and multiplied by your fleet size. Avoid:
- Calls to external services. These are technically possible, but an evaluation that depends on a network round trip runs on every scan and fails whenever the endpoint is slow or unreachable. Do that work in the remediation, where it runs on a schedule and its output is visible.
- Long-running operations. An evaluation that exceeds its execution window is reported as a failure rather than a result.
-
Anything that depends on a logged-in user. Evaluation runs as SYSTEM, so user-scoped paths and
HKEY_CURRENT_USERresolve to the SYSTEM account rather than the signed-in user.
Execution context
Evaluation and remediation both run as the SYSTEM account, and on Windows both run in a 32-bit PowerShell session. That has two consequences worth knowing when an evaluation behaves differently from the same code run by hand:
- On 64-bit Windows, a 32-bit process referencing
C:\Windows\System32is silently redirected toC:\Windows\SysWOW64, andHKLM\SOFTWAREis redirected intoWOW6432Node. Code that works in your own session can therefore check the wrong location under a Worklet. - Testing the evaluation manually on a device does not reproduce these conditions unless you deliberately run it 32-bit and as SYSTEM. See How to Test a PowerShell Script Locally for Worklets.
If an evaluation reports that something is missing when you can see it on the device, this redirection is the first thing to check.
Related behavior worth knowing
- A manual run skips evaluation entirely and executes only the remediation, so a manual run will not exercise your evaluation logic at all. See Why is the Evaluation Code Skipped When I Manually Run a Worklet?
-
Evaluation output does not appear in the Activity Log. It is available on the Device Details page under Device Logs as
policy_#####_test, where#####is the policy ID. - A non-zero evaluation exit reports the device as needing remediation, which shows as Pending Update. See Worklet is unexpectedly showing as "Pending Update"