In my WF, I have a requirement to send an email notification 6 months before an expiry date. The expiry_date is a list column and would be supplied by the user, so I get the value in my Nintex WF directly.
However, I'm a little confused about what's the best approach to do this. My current approach is:
1. Create a new workflow variable called "Reminder_date" and use the Calculated date action to subtract 6 months from my expiry_date and store the date in Reminder_date.
2. Use an inline function DateDiffDays(expiry_date,Reminder_date) and store the difference in another variable(say, difference_days).
3. Check if difference_days < 180 then send the email notification.
I've already done step 1. I'm not sure what action are best suited for Step 2 and 3. Any help is mush appreciated.
In a similar situation, I've approached this differently. You have the expiry_date field, so now you just need some way to check todays date against that date and respond accordingly. We use a workflow scheduler list for these types of operations. A site workflow could probably do the same. The scheduler list is on the same site collection as the list/library to operate on. A scheduled workflow is created in the scheduler list and is set to run nightly. It does a query of the list/library and performs the comparison between todays date and the expiry_date. If they're with the reminder date range, then send the reminder. If not, then exit.
Using workflows in a separate list can be a useful way of operating on random items in another list under special, non-editing situations. Site workflows do the similar.
Alrighty. After a little trial and error I finally solved it
The user requirement has changed a bit from my original question as now instead having a fixed 6 months reminder, the user is now able to select exactly how many months before s/he wants to be reminded.
The steps are as below:
1. Create a new local workflow variable called "Reminder_date" and store the Expiry_date (from the list column) in it.
2. Based on my requirement I've used a switch case to indicate user selection, but the underlying actions are the same. Use the "Calculate date" action to subtract 6 months from "Reminder_date" and store it in another variable called "Reminder_date_sixmonths"
3. Send a confirmation to user that s/he will receive a reminder on the date "Reminder_date_sixmonths" and include any relevant info. i.e. link to your document library, etc.
4. Use the "pause until" action to specify the date, in this case I'll pause until "Reminder_date_sixmonths"
5. Send the actual expiry reminder/notification on the date.
Sunil, looks like you came up with a good solution. I especially like the way you approached the user-specified reminder period. Hopefully having numerous workflows in a paused state for long periods of time won't be an issue for your configuration. It was something we wanted to avoid since we're constantly in a transition period.
We don't have much WFs running at the moment, so I thought having "workflows in paused state" won't be an issue for our configuration.
Initially I thought of using a separate workflow option to schedule a job which will loop through the Reminder dates and send out notifications, but I could not figure out how to configure it so I took this approach. However, I will appreciate if you could may be list out the impact of having workflows in paused state and if there is a way to avoid it.
For us the long paused state for workflows isn't about resources - it's more about the constantly-changing state of our implementation. We've been with SharePoint for some time now and just the process of migrating from SP2007 to SP2013 can take years. We have large amounts of record content in various forms - so we're always chasing a moving target. Its also a challenge with every update to SP2013 to ensure our production environments don't break. As the architect for our SP2013 implementation, it just made sense to me to limit any long-running workflow processes as much as possible to avoid conflicts with regularly scheduled maintenance & down-times.
In the case you described where you have a known expiration date or expiration period and a date to measure it against, one could eliminate a paused workflow altogether by using a scheduled workflow that ran daily and performed the date-differing checks. When the date requirements are satisfied you can execute the appropriate actions. If they're not met you just exit the workflow. In this way nothing is left outstanding in a paused state. Just a different approach to accomplish the same thing.