Schedules
Rebuild a completed audience on a recurring window, optionally re-exporting it each cycle. Conventions apply to every command here.
Schedules are a gated capability: they require additional permissions which need to be approved by your Account Manager.
Create
Set an audience to rebuild on a recurring window. See Create Schedule.
The audience must have completed before it can be scheduled. Each cycle moves the dates of the audience’s datasets to that cycle’s window. An Origin dataset’s window is widened to the whole Monday-to-Sunday weeks it touches, since Origin data is weekly. A cross purchase block keeps the dates it was built with, so every cycle reports purchases over the same window.
| Flag | Input | Lookup |
|---|---|---|
--name | letters, digits, spaces, _, and -, up to 255 characters | |
--audience-id | the audience to rebuild each cycle | audiences list |
--start | first run as YYYY-MM-DD HH:MM:SS, read in --timezone. Must be in the future | |
--timezone | a current region-based IANA name such as America/New_York or Asia/Kolkata, or UTC. Names outside a region, such as US/Eastern, GMT, EST5EDT, and every Etc/ name, are refused before anything is sent, --dry-run included. An older alias filed under a region, such as Asia/Calcutta, still passes that check and --dry-run, and the API rejects it | |
--frequency | how often it runs, case-insensitive | reference common schedule-frequencies |
--window | the data window id | reference common schedule-windows |
--window-days | day count from 1 to 365, for the custom window only | |
--ending | the stop rule id, Never by default | reference common schedule-endings |
--after-recurrences | run count, for the recurrences ending only | |
--end-date | the date the schedule ends, as YYYY-MM-DD, on or after the --start date, for the custom date ending only | |
--project-id | the project to file it under | projects list |
--file | the whole body as JSON, or - for stdin. Not combined with the flags above | |
--dry-run | print the body, create nothing |
Built from flags, a schedule needs --name, --audience-id, --start,
--timezone, --frequency, and --window. A longer --name is rejected
before anything is sent.
Without --ending the schedule never stops: it runs every cycle until you
deactivate or delete it. The recurrences ending stops after
--after-recurrences runs.
The custom date ending is turned into a run count when the schedule is
created: the run at --start plus every later run that starts by 00:00 on
--end-date. daily, weekly, and bi-weekly runs are 1, 7, and 14 days
apart, and monthly runs are one calendar month apart. So the end date itself
gets a run only when --start is at midnight or --end-date is the --start
date. A monthly schedule that starts on the 29th, 30th, or 31st runs on the
last day of a shorter month and stays on that day afterwards. An --end-date
before the --start date (read in --timezone) is rejected before anything
is sent, and the API rejects one in a --file body as well. See
Create Schedule.
A cycle that falls while your organization is over its monthly data-scan limit
is skipped: no audience is built, nothing is exported, and the schedule’s owner
gets a notification. The custom date ending counts a skipped cycle as one of
its runs, so the schedule makes fewer runs than the count above. The
recurrences ending does not, so it still makes --after-recurrences runs and
finishes later. See Usage.
Each stop rule carries its own field, and giving the wrong one is rejected
before anything is sent. The API rejects it as well. The custom window is the
only one that also takes --window-days.
intuizi schedules create --name "Weekly refresh" --audience-id <id> \
--start "<YYYY-MM-DD HH:MM:SS>" --timezone America/New_York \
--frequency weekly --window 4Replace the placeholder with a time in the future in --timezone. A past
start is rejected before anything is sent.
Re-exporting the audience every cycle needs an activation block, which goes
through --file. With one, a cycle’s audience is exported only when it
completes and passes the activation checks in
Activations for the schedule’s pricing
model. A cycle that fails them, or whose export falls while your organization
is over its monthly data-scan limit, is not exported, and the schedule read
does not say so.
List
Page through the schedules in your account. See List Schedules.
| Flag | Input |
|---|---|
--search | contains match on the schedule name |
--page --per-page | page through the results |
Show
Read one schedule by id. See Get Schedule.
The table shows the recurrence as {...}. --json carries it, including the
next run:
intuizi schedules show <id> --json | jq '.data[0].recurrence.cycles.next_run'Activate
Resume a paused schedule. The next run is at the next scheduled time. A run
the pause spanned is not backfilled, but the pause does not use it up either,
so a schedule with the recurrences or custom date ending still makes the runs
it had left when it was paused. With the custom date ending, that carries it
past --end-date by about as long as it was paused, and with an activation
block each of those runs is exported the way any cycle is.
Activating a Fulfilled schedule, one whose ending was met, sets it Active, but
it does not run again. When the schedule the API returns shows every counted
run made, intuizi schedules activate notes on stderr that it reads Active
but will not run again. To repeat it, create a new schedule.
See Activate Schedule.
Deactivate
Pause a schedule without deleting it. A cycle already building when you deactivate still completes and, with an activation block, is still exported. See Deactivate Schedule.
Delete
Remove one schedule. Audiences it built are unaffected. See Delete Schedule.
| Flag | Input |
|---|---|
--yes | skip the confirmation prompt |