Filter relative to the current time

Use NOW() in EQL filters to compare DateTime fields against the current time.

EQL filters can compare a DateTime field against the current time with NOW(). A filter such as Start > NOW() - 7d AND Start <= NOW() matches jobs that started in the last seven days, and keeps matching the right jobs every time it runs, without you rewriting the date.

You can use NOW() in these EQL filters:

  • GraphQL queries, including filters on nested lists
  • GraphQL subscriptions
  • GraphQL webhooks and deferred webhooks
  • Object modified triggered actions, including deferred triggered actions
  • Record access policy rules (Skedulo Pulse Platform only)
  • Automation filters on record modified, record time offset, and event triggers

Syntax

NOW()
NOW() + <offset>
NOW() - <offset>

The offset is a whole number followed by one of these units:

Unit Meaning
ms milliseconds
s seconds
m minutes
h hours
d days of exactly 24 hours, ignoring daylight saving changes

For example:

Start > NOW() - 7d
Start >= NOW() AND Start < NOW() + 2h
End < NOW() - 30m

Follow these rules when you write a NOW() expression:

  • Write NOW in uppercase. now() and Now() are rejected.
  • Put NOW() on the right-hand side of the comparison. Start > NOW() is valid, NOW() < Start is not.
  • Use at most one offset. Write NOW() - 26h instead of NOW() - 1d - 2h.
  • Use the short units in the preceding table. NOW() - 7days and NOW() - 1 hour are rejected, although the long unit names work in other duration literals.
  • Keep the offset within 36,500 days (about 100 years) either way.
  • Spaces around the sign are optional. NOW()-7d, NOW() -7d, and NOW() - 7d mean the same thing.

A filter that breaks these rules is rejected with a parse or type error when you run the query or save the webhook, triggered action, rule, or automation.

Supported fields and operators

NOW() is an Instant, the same type as an Instant literal, and Skedulo works it out to the millisecond. You can only compare it with DateTime fields, such as Start, End, or CreatedDate. Use the operators ==, !=, <, <=, >, and >=.

You can’t use NOW():

  • against Date or Time fields, because turning an Instant into a date needs a timezone
  • inside an IN or NOTIN list
  • with LIKE or NOTLIKE
  • against string, number, or duration fields

What “now” means

Skedulo never stores NOW() as a fixed time. It keeps NOW() in the filter and works out “now” each time the filter runs. Every NOW() in one evaluation uses the same time, so Start >= NOW() AND Start < NOW() + 2h describes an exact two-hour window.

Where the filter runs “Now” is
GraphQL queries The time Skedulo received the request. All queries in one request, including every operation in a batch request, share the same time.
Subscription, webhook, and object modified triggered action filters The time Skedulo recorded the change.
Queries a webhook or triggered action runs to build its payload The time Skedulo runs that query. For a deferred webhook or deferred triggered action, this is when it fires.
Record access policy rules The time Skedulo checks the user’s access to the record.
Automation record modified and event triggers The time Skedulo recorded the change or event.
Automation record time offset conditions The time Skedulo recorded the latest change to a field the trigger depends on. When you create or activate the automation, or change its trigger, it’s the time Skedulo checks existing records.

Payload queries include filters on nested lists in a webhook query and the GraphQL query in a Call URL triggered action.

Because change filters use the time Skedulo recorded the change, a change that waits in a queue or is retried gives the same answer it would have given straight away. This doesn’t apply to record access policy rules, which always use the time of the access check. For example, a triggered action with the filter Current.Start > NOW() fires for a job whose start time was still in the future when someone saved it, even if Skedulo processes the change after the job has started.

A record time offset condition works the same way. Skedulo checks the condition only when a field in the condition, the anchor field, or the offset field changes, and doesn’t check it again when the scheduled time arrives. So Start > NOW() in a condition means the job’s start time was in the future when someone last changed one of those fields.

A deferred webhook or deferred triggered action checks its filter against each change to the record, using the time Skedulo recorded that change. It doesn’t check the filter again when it fires, so NOW() in its filter means the time Skedulo recorded the change, not the time it fires.

Records with an empty DateTime field

When a DateTime field such as Start is empty, the result of a comparison depends on where the filter runs.

  • GraphQL queries on the Skedulo Pulse Platform never match a record whose field is empty, whatever the operator. On Skedulo for Salesforce, != matches records whose field is empty and the other operators don’t.
  • Subscription, webhook, triggered action, and automation trigger filters treat an empty value as earlier than every point in time. So <, <=, and != match a record whose field is empty, and >, >=, and == don’t.
  • Record access policy rules follow the query behavior when a user queries records. When Skedulo decides which changes to send to a subscriber, simple rules follow the subscription behavior. Rules that need a database check, such as rules with a subquery, follow the query behavior. A rule such as Start < NOW() can therefore send a subscriber a job with no start time that the same user’s queries don’t return.
  • Record time offset conditions follow the query behavior when Skedulo checks existing records after you create or activate the automation, or change its trigger, and the trigger filter behavior for every later change.

This also applies to comparisons with a fixed date, except in automation trigger filters. There, comparing an empty field with a fixed date using <, <=, >, or >= causes an error, and the automation doesn’t run. If records with an empty field matter to you, say so explicitly in the filter. For example, use Start != null AND Start < NOW() to leave them out, or Start == null OR Start < NOW() to include them.

Examples

Jobs that start in the next two hours:

query {
  jobs(filter: "Start >= NOW() AND Start < NOW() + 2h") {
    edges {
      node {
        UID
        Name
        Start
      }
    }
  }
}

Jobs that were created in the last seven days and are still queued:

CreatedDate > NOW() - 7d AND JobStatus == 'Queued'

A subscription that only reports changes to jobs starting within the next day:

subscription {
  schemaJobs(filter: "Start >= NOW() AND Start < NOW() + 1d") {
    operation
    timestamp
    data {
      UID
      Start
    }
  }
}

An object modified triggered action filter that fires when a job is rescheduled to start within the next hour:

Operation == 'UPDATE' AND Current.Start != Previous.Start AND Current.Start >= NOW() AND Current.Start < NOW() + 1h

A record modified automation trigger that runs when a job is rescheduled to start within the next hour:

current.Start != previous.Start AND current.Start >= NOW() AND current.Start < NOW() + 1h

The automation builder can’t show a NOW() filter in Simple mode, so you write it in Advanced mode.