31% of Part II — dates, conditions, and verifying the result.
3 tasks · this deck covers task 2 of 3
↑ Update Profile Attributes OverviewCalculated dates (Task 1) only drive an attribute update once you can test them against a condition — "has this date passed?", "is this within N days?" — and branch accordingly. That's the Expression function.
Comparison operators: == != > >= < <=. Logical operators: and, or, not, xor. Parentheses group sub-expressions. # starts an inline comment.
"Date fields convert to a timestamp that will work in comparisons." That's what makes it possible to write an expression like a term-end date compared against Now — both sides resolve to comparable timestamps.
If a modify-dates condition also needs to check a text field (e.g., "and status equals 'Staged'"), that piece has to be evaluated with the separate Compare function — not folded into the same Expression.
Okta's own "Tutorial: Time-based actions" walks through exactly this pattern end to end: create a contractor user in Staged status, calculate term dates, then later activate the account on the start date and automatically suspend it after a designated time — using a table to track the dates, and helper flows to act on them.
Watch for this in your own sandbox run:
→ Trying to compare two text fields directly inside an Expression card — swap to Compare for that piece.
→ Forgetting that a number field evaluates to false only at exactly 0, and a text field evaluates to false only when null or the literal string "false" — everything else is truthy.
Sources: help.okta.com — Expression (type=wf&id=ext-boolean-method-expression); Tutorial: Time-based actions (type=wf&id=ext-tutorials-time-based-actions)
Next: Task 3 →