Hello,
I have created a BPM on pre-processing but the email is firing whenever the customer record is saved, rather than the credit hold field changing from True to False. Can anyone help ?
Thanks in advance.
2 Likes
Move it to Post-Processing so the data is saved before the email is sent. One thing that i find useful is to pop an info message in after the condition to see if it is firing.
I might be wrong but I think Customer.Update does trigger when the record is saved. Have you tried running a trace log to see if there is another method you could hang your email on?
Have you looked into Global Alerts?
well spotted, still same behavior after changing it unfortunately.
Hold up, what are you wanting to happen?
This bpm as designed is only going to fire when update is called.
If the credit hold flag (Customer.CreditHold) or the Aging Credit Hold flag (Customer.AgingCreditHold) is taken off (so goes from True to False) then I want it to send an email.
This is a job for a data directive.
Just looking now, need to find some documentation on these as I can see a list of the global alerts, but no option to create a new one.
I don’t think you can actually create one. I think they come premade. There is one for when a customer credit hold status has been changed:
If you check Send Alert you can then fill in the email information. I’m not super knowledgeable about the global alerts but we do use a couple.
Thank you, I am looking at data directives now, I can get it to show an alert to show when you untick the box, now just to figure out how to send an email.
I currently have a Method Directive in place that sends a separate email depending if the Customer is going on or coming off Credit Hold.
Thank you, I have it working (I think!) through a data directive. 
I’ve recently enabled this for our business, and it works perfectly. No BPM needed, just nice straightforward, built-in functionality for a change!
I only recently started using them but as you said, it’s actually easy to use and seems to work flawlessly.
1 Like
the reason that this requires a data directive is simple… Not all updates are done via the Customer.Update method. Yes, the customer.update method IS called when you do it from the customer entry screen, but there are other apps that will fliip this flag, and it might be done via another thing (maybe something like “customer.CreditCheck”, or something else… just guessing). I do know that when you run certain apps like invoice posting or order entry that the customer will go on/off credit.
BUT… if you use a DATA directive, it doesn’t matter what business object does the work. the data directive will always fire.
BIG WARNING… note that I said that it will ALWAYS FIRE after EVERY CHANGE… this makes it important that when you make a data directive that you make the first statement(s) some sort of filter looking for a specific thing before firing off additional logic. I have seen companies associate a data directive to something as common as PartPlant, and do some secondary searches and write to a secondary table every time it changes. this type of thing can be a huge burden on the system, especially during MRP runs or anything else that does mass changes to the PartPlant table.
4 Likes