BPM to email SO Ack Form

Not natively Yash.

TBH, I loathe the idea of emailing directly from applications - including Epicor. With email attachments being a vector for malware, it seems unwise to mix good documents with bad. :man_shrugging:

We’ve had this discussion on another thread but I would prefer separating the concerns of creating documents from notification. In my mind, the best path is to create the document and store it in DocStar, SharePoint, etc. and then create rules about how to notify users (email, portals, Teams/Slack message, etc.) however the users and customer wants to be notified and not how we in IT decide they need to need to be notified. Separating the concerns gives us far more opportunities than we have just pushing emails out of applications.

Understood, thank you for the recommendation. I like the idea of creating a portal that links to the repository.

And both DocStar and SharePoint have workflow where you can still do email if you wish…

The RDD for OrderAck creates a field named Calc_EmailAddress (or something close to that). It does some magic when determining which of the many email addresses it could use.

You could add a UD field to OrderHed, to hold a list (semicolon separated) of the various email addresses this OrderAck needs to go to. Then the B/R would have access to that field.

And yes, I skipped an important hint when making a new B/R. You can’t change the RDD used by the B/R after the B/R has been created. And since you cannot change a built-in RDD, you should make a copy, and then use the copy for the style you’re adding a B/R to. That way if you later need to tweak the RDD (like including a UD field), you can do it without having to build the whole B/R from scratch.

1 Like

The thing I loathe most about RDD is that you can’t alias tables and use the same table with a new alias. This has caused us SO many issues, since we put SoldTo, BillTo and ShipTo Contacts (as UD fields) on a LOT of the tables where Epicor doesn’t have them.

That said, if you can get the contacts, it’s not hard to use APR for mailing. The ‘default’ for the OrderAck seems to be to the salesrep in charge of the order, which is how we use it for one of our companies. But we do have one that wanted to make it customer facing, which turned out to be quite the challenge.

I think the rule is actually tied to the report style, not the RDD itself. We use the same RDD for both companies, but a different report style. In the properties for the Report Style, you can set which companies can use it and which is the default for a given company.

image
image

These are the 2 relationships I created to link orderhead to shipto. The email addresses we want to use are stored in the ShipTo.EMailAddress field. I created a separate shiptoID for each customer contact. When we choose a specific shiptoID in the orderhead, the email still goes to all shiptoid email addresses not the specific one we tell it to. Is there something I am missing?

How are you specifying the one you tell it to go to?


This is what the breaking/routing design looks like, and what field is used to select the To: field in the email template

Yash, where on the order are you selecting a ship-to contact?

That field should already be built into the dataset- in which case you don’t need to do that join to ship-to.

So on the order I am selecting a shipto id, and on the back end under customer we are creating new shipto id’s for each contact so the email address field in customer->shipto-> detail-> email is what is being used at the moment. Hope that makes sense, and maybe there is an easier way to go about this?

Yeah, create a primary purchasing contact for each of the ship-tos and then it should default into the sales order. Look at the fields circled in red. Use field help.

So if there are multiple primary contacts per shipto, it should email to all within that shipto list?

No Yash, it can’t do multiple unless you want to try some of the suggestions that others have given you. The breaking and routing won’t do that either… it doesn’t send to each ship to ID you have.

That is what @Mark_Wonsil is trying to say to you and what @MLamkin was getting at.

If I customized the order entry form and added a checkbox for revised acknowledgement, could I design it to where if it’s not checked off then use a specific email template and if it is checked off then use a different one?