Feature Request: initialWindowTime

[tantonw]

We have approachingWindowTime and imminentWindowTime, and it would be useful if we had initialWindowTime. We'd like to be able to pre-configure a Nudge profile to not bug users at all until a certain amount of time away from the requiredInstallationDate. The idea is that Nudge would quit silently (i.e. it would be in the "Inactive" phase) until initialWindowTime was reached. This would allow admins to configure the Nudge profile in advance, and not have to do it specifically on the day that you wish to start nudging.

For example, an org wants to set requiredInstallationDate to 30 days after an update is released, imminentWindowTime to 24 hours, approachingWindowTime to 72 hours, but to also not bug users at all for the first 15 days. As it is now, an admin has to update the Nudge configuration on exactly day 16 after update release. If initialWindowTime was a thing, the admin could just set it to 15 days and then would be able to update the Nudge configuration at any point in the first 0-15 days after update release.

[bradtchapman]

@tantonw : you need to do a few things:

1. disable the allowUserQuitDeferrals;
2. Don't configure an initial cycle.
3. Make your approaching cycle a bit longer aka treat it like the initial cycle.
4. Use a gentler reminder interval during the approaching cycle.

This will prevent users from selecting a deferral date way into the future, and then they'll get notified multiple times a day during the approaching cycle.

We use 4-hours (14400 seconds).

@erikng : what do you think about this one?

[erikng]

nudgeEventLaunchDelay will be a new key you can use to artificially grant some buffer time. This will impact all of your refresh cycles. It was designed in mind for the new automated nudge events for SOFA, but it will work for this use case.