To avoid the whole risk associated with messing with SysTask, BAQ export call variability by version, or buying the third party software, I’ve started using a user code type called AUTOPROC, then placing a directive on the user code update that runs your custom code if the user code modified is your certain code (e.g. “AutoShipEmail”) and LongDesc is updated (to the current datetime or something). Then, you can call this update through whatever you want: REST, DMT, PowerShell DMT, and the code can be static and the meat and potatoes can be stored in the BPM. This does have the external dependency of the trigger and execution of the simple user code update; I am doing this through PowerShell DMT on a windows task schedule, which is easy enough and requires no SQL permissions.
Thank you. I thought it might not be such a good idea but wanted to check (and reading back have realised it had already been asked and answered).
I also hadn’t realised that Updatable BAQ Method Directives were under a separate menu item - I now have this working but I have given my boss all our options.
Hi @josephmoeller,
thanks for sharing your idea, is it possible to kindly share your example of triggering user code update using scheduled task from PowerShell UI ? it looks like my epicor version does not respond with UBAQ scheduled export
we have achieved similar results through SQL jobs.
The original use case: if you don’t have to move any data, you should just create a report routing that splits on your PackNum and sends emails, then run it on a schedule. - Tracy’s add should probably just be a new thread to not confuse.
How about triggering the BPM at SysAgentSched table ?
The value of NextRunOn field will change daily if scheduled daily.
Our directives have a slightly different purpose, so what we have works for us, I was just commenting from experience of having implemented BPMs on SysTask tables in general. When we do scheduled things it tends to be via Service Connect.
But yours would be an interested idea to test.
have you done it and worked ?, it sounds very good idea less expensive than adding the code to the SysTask 
update:
just tried it, it is working fine mate, many thanks for this idea
Does that fire if there are no tasks assigned to the particular AgentSchedNum in the condition block?
My guess is yes, because it needs to update the LastRun field.
Good to see it working 
you need to assign it to at least one record, then it depends on that task scheduled time and the enabled flag, i.e. you will have a full control, it is exactly what i was looking for, with a massive advantages over the SysTask which is very expensive idea and will affect overall performance, this will supersede PowerShell, uBAQ export, and running a re-defined SSRS report to scan values, straight away put the code here to find your record or list or records, then do whatever you want, e.g. check field values, pass parameters and invoke what ever method you want, send alerting emails, attached documents…etc
One possible hiccup … Would the SysAgentSched.Update fire when you change the time on the switch of Day Light Saving time?
Maybe add another condition line that it has to be within a certain time of day. Like when the scheduled task runs (giver or take 30 minutes)
the schedule i picked is an instant one, so this factor won’t matter, Epicor has many light process within it it can be set as a scheduled task mine was filling the shopload graph, but you can pick an easy and quick one for your environment then control it the way you want.
my Epicor environment converting the server time to the UI, i.e. my test has been triggered at 9:15am which equivalent to 8:15am on the server time
I guess I really meant to say that any change to the NextRunOn - like through the UI (using Sys Agent Maintenance), would cause it to fire.
I only used the DST change as an example of why someone would ever go into Sys Agent Maint and manually change the Next Run value
yes it will, if you want to exclude the manual change, you can add another condition saying and user client is Manager OR user is not belong to security group such and such
We just recently tried this method of running BPM code based on ‘nextRun Date’ change , it seems to work well. Curious as to why our new ‘scheduled task’ does not show up in the system monitor as a scheduled task, also does not show in ‘history’ after running? My guess is we have a flag or similar not set, or something else not properly set up in the scheduled task.
Yes still can’t see it.
Does it show in the Task Agent Maintenance?