Flow Designer gives you access to the triggering record through trigger.current, not the workflow.current you might expect from classic workflows. This is a live GlideRecord instance pointing to the exact record that started the flow, but it's only populated when the flow was actually triggered by a record operation. Most developers trip up by assuming it's always there or by trying to query for the record again using inputs values—you already have the record, properly initialized and ready to modify.

When to use this pattern

  • When your flow is triggered by record operations (created, updated, deleted) and you need to read or modify that specific record
  • When you need to update multiple fields atomically on the triggering record without additional database queries
  • When you need to access reference field display values from the original record context
  • When implementing complex business logic that requires both reading current state and updating fields in a single transaction

When NOT to use this

  • Don't use this in flows triggered by schedules or manual starts—trigger.current will be null. Use flow inputs or lookup records instead
  • Don't use this for read-only operations that could be handled by Flow Designer's built-in data lookups—use lookup records step instead
  • Don't use this when you only need to pass field values to subsequent flow steps—use the trigger step's data pill outputs directly
  • Don't use this to create or query other records—use Create Record or Lookup Records steps for better maintainability

Key behaviors and gotchas

  • trigger.current is null in scheduled flows, manual flows, and flows called via REST—always null-check before use
  • Changes made to trigger.current require calling update() to persist—they don't automatically save like workflow context variables
  • Reference field values accessed via getDisplayValue() reflect the state at flow trigger time, not current database state
  • Choice field values are integers as strings—state.toString() returns '1', '2', '6', etc., not 'New', 'In Progress', 'Resolved'
  • Updates to trigger.current will fire business rules and workflows on the target table—plan for recursive triggers
  • ACL enforcement applies to update() operations—flows run in system context but field-level ACLs may still block updates
⚠️

Never assume trigger.current exists without null-checking. Flows can be executed manually, scheduled, or called via subflow where no triggering record exists, causing your script to fail with 'Cannot read property of undefined' errors.

Free Newsletter

Enjoying this? Get one deep-dive per week.

Join 1,000+ ServiceNow pros — scripts, GlideRecord patterns, Flow Designer techniques, and career moves. Free.

No spam · Unsubscribe anytime