Hi,

AWRKMEL may not run anymore (for obvious reasons), but there is still a workaround to this issue.

Since script AWRK still needs to get called to build the message, you can use entry point MESSAGE in script AWRK. The only thing you need to have is a classic user that contains the email of the notification server. Variable USRWRK is the code of the user that triggered the workflow. The script below changes the user that triggered the workflow it to someone else. When it goes to send the email, it takes the email from that new classic user.

If you add an entry point to script AWRK, your specific script in the entry point can say something like this:

---

$ACTION
 Case ACTION
  When "MESSAGE" : Gosub MESSAGE
  When Default
 Endcase
Return

$MESSAGE
 If [F:AWA]CODE = "BLKUSR" #conditional is optional, in this example I say to change only for workflow BLKUSR
  USRWRK = "MYUSR" #where MYUSR is classic user code containing the email of the notification server.
 Endif

Return

---

This was tested in V12 P33 with success.

Regards,

Andrew

Hi,

AWRKMEL may not run anymore (for obvious reasons), but there is still a workaround to this issue.

Since script AWRK still needs to get called to build the message, you can use entry point MESSAGE in script AWRK. The only thing you need to have is a classic user that contains the email of the notification server. Variable USRWRK is the code of the user that triggered the workflow. The script below changes the user that triggered the workflow it to someone else. When it goes to send the email, it takes the email from that new classic user.

If you add an entry point to script AWRK, your specific script in the entry point can say something like this:

---

$ACTION
 Case ACTION
  When "MESSAGE" : Gosub MESSAGE
  When Default
 Endcase
Return

$MESSAGE
 If [F:AWA]CODE = "BLKUSR" #conditional is optional, in this example I say to change only for workflow BLKUSR
  USRWRK = "MYUSR" #where MYUSR is classic user code containing the email of the notification server.
 Endif

Return

---

This was tested in V12 P33 with success.

Regards,

Andrew

Confirmed!

For reference:

Then edit in the specific script from Andy S above.

You can setup sender Email address in Workflow setup in latest release.

Yes (since v12p33), but I need to add the Sender email on all the workflow rules (GESAWA).

Which sounds tedious for every new workflow rules created and when management decided to change email providers.

I would prefer creating Entry Point to AWRK as compromise to set once and forget.

It would be nice if I can just set once and forget from Administration > Notification Server but Sage X3 tech not there yet.

Have you considered seeing if adding a default value to field SENDMAIL in screen AWA3 so that at least for future created workflows, the Sender line gets filled automatically? Then also add a control to say that the field is both mandatory and must be that email value so when someone goes to modify the workflow, it forces their hand?

You can then mass update table AWRKPAR SENDMAIL field with your email and the just have to validate your workflows again. So a bit of pain at the beginning, then smooth sailing afterwards.

On the edge case of management decided to change email provider or email sender, won't I have to:

1. Run the SQL script to mass update the Workflow Rules table, and

2. Then on X3 side, run a full dictionary validation to force Workflow rules acknowledge the new SENDMAIL?

Over just editing the YAWRK user's workflow email, for the Entry Point workaround method?

Fair points. It was just a thought if you wanted to rid yourself entirely of an entry point dependency while giving some protection against people mangling new or existing workflow setups. I'm certainly not going to argue over continuing to use a solution I suggested after all.

As an update, I just realized after testing that sender email is strangely a formula field instead of a free field. 

So therefore, you could get rid of your entry point dependency.

Example:

Put your email address in a general parameter and make default value in the screen to be the parameter (along with a control to force the value to be the formula). When the default email changes, you just update the general parameter value and you're done.

Reference from my internal Sage X3 developer:
- Creation: https://www.greytrix.com/blogs/sagex3/2013/03/26/creating-parameter-values-in-sage-x3/
- Fetching: https://www.greytrix.com/blogs/sagex3/2014/04/28/fetching-the-parameter-values/

For reference, my side:

Create parameter value entry.

Enter the custom parameter value entry

Formula used: `func AFNC.PARAM("YSENDMAIL","")`

Tested on Microsoft account, seems like issue reoccurs. Data does pull in Recipient level but not on Sender e-mail level.

On Analyze formula at Sender email side.

Does the user (M365 email account) that the notification server is set to authenticate with have permissions to send as the user you are sending as?  
The SendAsDenied error is coming from M365.  In Exhange management give the authenticating user permissions to send as the other user.

The plan is for single dedicated sender email address only, for any email provider.

Microsoft is used as a common punching bag here but I do have to handle non-standard self-hosted emails providers where it can be expected there is no configuration for it.

[email protected] is a placeholder for client's dedicated M365 sender email since I was using client's dedicated sender email to test on the spot.

I am currently barred from testing on client's dedicated sender email by the client already so if there is a way for me to test this feature normally without subscribing to yet another Microsoft trial subscription (company not using Microsoft365) with either phone number or credit card number, that would be good.

Additionally, how do I access the M365 configuration for the mailbox shown in the screenshot?

Can you help me understand?  I'm not sure I understand what the control would be to force the value to be the formula. 

Thank you.

The screenshot from the mailbox settings in M365 Exchange Admin Centre.

Have you tested sending as the user that the notification server is set to authenticate with?

I have not.  I am trying to determine if a script to force the from address is truly necessary.  All the errors are just as you said, because the email is not allowed to send as, however I am being told that a script on the entry point is required because the sender's email field on the Notification server doesn't work. 

If you are using MS365 which only allows one sender email address, then the control ensures users cannot change it to something else as it will fail if they do.

The entry point is only required if you are below V12 patch 33 as the sender email field on the workflow doesn't exist before P33. We have done the solution I posted here for several clients now without issue.

while creating the parameter, I ran into a character limit of 20.  The email address is >20.  Any suggestions?

The values section in parameters is only if you want predefined values to choose from when you set your actual parameter value in the parameter values function. AN alphanumeric parameter can hold a value up to 250 char. So just leave the values section blank in the definition and be sure to check the "off-value" and "changeable" checkboxes when creating the parameter.