Using Outlook wrt New email client for Sage X3 workflow notifications post.

SOLVED

Reference: https://www.sagecity.com/us/sage_erp_x3/f/sage-x3-announcements-news-and-alerts/187389/new-email-client-for-sage-x3-workflow-notifications

I am using a Microsoft Outlook account (assume name as [email protected]) which requires FROM to match the email relay's email account used (in this case: [email protected]).

I switch over to the new email client and did the settings as per the post.

The email relay test mail is all OK.

When I do a direct workflow email

```

Application error
error : 4 Message failed: 554 5.2.252 SendAsDenied; [email protected] not allowed to send as [email protected]; STOREDRV.Submission.Exception:SendAsDeniedException.MapiExceptionSendAsDenied; Failed to process message due to a permanent

```

I was login as ADMIN and the workflow email set for this user is: [email protected]

Previously, I would use a customized YAWRKMEL (based on AWRKMEL script) to resolve this issue by hardcoding in the sender mail address but this script seems to be skipped out.

How to resolve this without recommending using other email providers like GMail or installing a dedicated email relay inside the server or setting every user to use the sender email?

Parents
  • +1
    verified answer

    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

  • 0 in reply to Andy S

    Confirmed!

    For reference:

    Then edit in the specific script from Andy S above.

  • 0 in reply to chunheng

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

Reply Children
  • 0 in reply to Charlie Cai

    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.

  • +1 in reply to chunheng
    verified answer

    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.

  • 0 in reply to Andy S

    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?

  • 0 in reply to chunheng

    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.

  • 0 in reply to chunheng

    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.

  • 0 in reply to Andy S

    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.

  • 0 in reply to chunheng

    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.

  • 0 in reply to Carl Herrmann

    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?

  • 0 in reply to Andy S

    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.

  • 0 in reply to chunheng

    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?

  • 0 in reply to Carl Herrmann

    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. 

  • 0 in reply to Kaycee

    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.

  • +1 in reply to Kaycee
    verified answer

    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.

  • 0 in reply to chunheng

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

  • 0 in reply to Kaycee

    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.