> For the complete documentation index, see [llms.txt](https://help.usejimo.com/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.usejimo.com/docs/publish/trigger-at-the-right-time-when/planning-your-experience.md).
# Schedule, recurrence and priority
Reference for the When settings: start and expiration dates, recurrence options, and priority between live experiences.
The reference for the three settings of When that belong to each experience. For which combination to pick, start from [When](/docs/publish/trigger-at-the-right-time-when.md#frequent-combinations).
***
## Start and expiration
Under **Select when the experience is live**, two dates: when it goes live, and when it expires.
#### Start date
By default an experience starts when you publish it. Set a start date and time in the future to publish now and go live later, without coming back to it on the day: the usual choice for a campaign. Until then the experience reads as **Scheduled** in the dashboard.
The picker accepts a date in the past too, and keeps it. On a draft the chip still reads **Now**; once published, the experience is live at once and the chip reads **Has been live since** that date. This is how you migrate a changelog from another tool and keep the original publication date of each post, see [Post Builder](/docs/experiences/changelog/posts/post-builder.md).
The date and time you pick are read in the timezone of your browser, the one your computer is set to when you edit the experience, and the chip shows them in your browser's date format. Jimo stores that exact moment and does not convert it to each end user's timezone: a start set at 9:00 from Paris goes live at 9:00 Paris time for everyone, 3:00 in New York.
{% hint style="info" %}
**Back to "now".** Clear the start date with its cross to make the experience live as soon as it is published.
{% endhint %}
#### Expiration date
By default an experience runs with no end. Set an expiration date for a campaign, a feature release or a time-limited offer. At that date the experience is paused. The expiration time follows the same rule as the start: your browser's timezone, not the end user's. The calendar does not let you pick an expiration earlier than the start date.
{% hint style="warning" %}
**Removing an expiration date does not restart an expired experience.** It stays paused. Set it live again from the dashboard, where you can pause and restart any published experience.
{% endhint %}
## Recurrence
Under **Select experience recurrence**: how often the same user can see the experience again.
#### Show once
The default, and the safe choice: users who skipped the experience are not asked again. A user who has seen the experience does not see it again. The right choice for welcome messages, announcements and most tours.
What counts is the first step: the experience is done for a user once they have seen or completed its first step. The exact moment can vary with the kind of first step: a modal, a snippet, a tooltip or a hotspot.
#### Show every
**Show every** \[N] \[unit]: the experience can show again after the number and unit you set. Use it for reminders, a survey you repeat, or an announcement you know comes back, for example every 90 days for an NPS. The unit is **Day**, **Week** or **Month**; your assistant can set the same interval.
#### Show every time
The experience shows each time the user meets the trigger. Useful while you test, for persistent guidance, or for a light hint on a page users come back to. Rarely right for a modal. Switch it back before you widen Who, see [When](/docs/publish/trigger-at-the-right-time-when.md#frequent-combinations).
{% hint style="info" %}
When does not apply to an experience with No automatic trigger: it shows each time another experience launches it. An experience On shared URL shows each time the link is opened. See [Show on](/docs/publish/trigger-on-the-right-spot-show-on.md).
{% endhint %}
## Priority
Under **Select experience priority**. When several experiences are eligible on the same page at the same time, usually because they target the same URL, the one with the highest priority shows first. A new experience has priority 0. Give a higher number to the one that must win: an experience with priority 10 shows before one with priority 9, for example 10 for a billing notice and 0 for the rest. The field takes a whole number from 0 to 999.
Under the field, the help text reads "Experiences with higher priority will be shown first", above the list of your experiences and their priority, so you can place the new one among them.
The **Rate limiting** checkbox sits in the same block. It is covered in [Rate limiting](/docs/publish/trigger-at-the-right-time-when/rate-limiting-prevent-overwhelming-users.md).
## How the three combine with rate limiting
Each setting answers a different question for the same user, on the same page.
| Question | Decided by |
| --------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------- |
| Is the experience live right now? | Start and expiration |
| Can this user see it again? | Recurrence |
| Several are eligible: which one goes first? | Priority |
| This user just saw one: can they see another? | [Rate limiting](/docs/publish/trigger-at-the-right-time-when/rate-limiting-prevent-overwhelming-users.md), project-wide |
Best practices
* **Timing.** Launch when your users are most active, or when they are least busy, based on your analytics.
* **Test timings.** Try different moments, and keep the one that engages most.
* **Schedule campaigns.** A start date makes a promotion go live on time without anyone at the keyboard.
* **Repeat what must be seen.** For an important announcement or a compliance notice, a recurrence reaches users who missed it the first time.
* **Review priorities.** Adjust them when your goals change, or after user feedback.
* **Mind the cap.** Tune [rate limiting](/docs/publish/trigger-at-the-right-time-when/rate-limiting-prevent-overwhelming-users.md) to keep users from seeing too many experiences.
## From your assistant
Ask: *"Show the Welcome modal again every 2 weeks, priority 10."* The preview shows the current and the new recurrence and priority before anything changes. More in [What to ask?](/docs/integrations/mcp/what-to-ask.md)
## Related
* [When: schedule and frequency](/docs/publish/trigger-at-the-right-time-when.md)
* [Rate limiting](/docs/publish/trigger-at-the-right-time-when/rate-limiting-prevent-overwhelming-users.md)
* [Test safely](/docs/getting-started/publish-your-first-experience/test-safely.md): reset what your browser has seen.
{% endhint %}
#### Expiration date
By default an experience runs with no end. Set an expiration date for a campaign, a feature release or a time-limited offer. At that date the experience is paused. The expiration time follows the same rule as the start: your browser's timezone, not the end user's. The calendar does not let you pick an expiration earlier than the start date.
{% endhint %}
## Recurrence
Under **Select experience recurrence**: how often the same user can see the experience again.
#### Show once
The default, and the safe choice: users who skipped the experience are not asked again. A user who has seen the experience does not see it again. The right choice for welcome messages, announcements and most tours.
What counts is the first step: the experience is done for a user once they have seen or completed its first step. The exact moment can vary with the kind of first step: a modal, a snippet, a tooltip or a hotspot.
#### Show every
**Show every** \[N] \[unit]: the experience can show again after the number and unit you set. Use it for reminders, a survey you repeat, or an announcement you know comes back, for example every 90 days for an NPS. The unit is **Day**, **Week** or **Month**; your assistant can set the same interval.
#### Show every time
The experience shows each time the user meets the trigger. Useful while you test, for persistent guidance, or for a light hint on a page users come back to. Rarely right for a modal. Switch it back before you widen Who, see [When](/docs/publish/trigger-at-the-right-time-when.md#frequent-combinations).
{% hint style="info" %}
When does not apply to an experience with No automatic trigger: it shows each time another experience launches it. An experience On shared URL shows each time the link is opened. See [Show on](/docs/publish/trigger-on-the-right-spot-show-on.md).
{% endhint %}
## Priority
Under **Select experience priority**. When several experiences are eligible on the same page at the same time, usually because they target the same URL, the one with the highest priority shows first. A new experience has priority 0. Give a higher number to the one that must win: an experience with priority 10 shows before one with priority 9, for example 10 for a billing notice and 0 for the rest. The field takes a whole number from 0 to 999.
Under the field, the help text reads "Experiences with higher priority will be shown first", above the list of your experiences and their priority, so you can place the new one among them.
