Send Email Step inconsistent

1081
9
Jump to solution
02-17-2023 07:11 AM
bbaker_tngeo
New Contributor III

I'm having issues with the Send Email step not working consistently in a 10.9.1 workflow and am trying to rule out potential causes. First, is there is a minimum Role group that is required to send emails? Secondly, the steps that are not sending emails are using the following Arcade Expression that could be the reason the emails aren't sending. For reference, I am using the same expression (minus the "quotation marks") to update the path assignment with the username property and that is working. Is there something else that may cause inconsistent emails? If I run through the whole workflow with an Admin user everything works.

TO: "GetUser($currentPortal, jobExtendedProperty ($job, 'details', 'fieldcrew'))['email']"

 

PATH ASSIGNMENT: GetUser($currentPortal, jobExtendedProperty ($job, 'details', 'fieldcrew'))['username']

 

*Update: I added a CC to an email address and the step is running and delivering the email, but not to the email that I am trying to pull using Arcade. I will also add that when I preview the step, the expression is successfully pulling the email address, so I'm not sure why it isn't populating the TO address when the step runs.

0 Kudos
1 Solution

Accepted Solutions
JFarmer
Esri Contributor

@bbaker_tngeo 

Thanks for the reply and sorry for the delay in mine.

What you are seeing here is correct. If the goal was to get the email address for a different user and the user running the step in Workflow Manager was not a Portal Admin, they would need this privilege. 

As a workaround, you could assign the Send Email step to a Portal Admin if that was a desire rather than having a custom Portal role. 

We'll work on better documenting this to help cut down on confusion in the future.

Jonathan

View solution in original post

0 Kudos
9 Replies
JFarmer
Esri Contributor

@bbaker_tngeo 

Is there also a path assignment user change happening around the Send Email step in this case? You said the Arcade expression is working fine and returning an email address but not the one you want. Is is pulling an email address for the user that was assigned the Send Email step? There may be some tweaking you need to do so that the email sends to the correct user and then the path after that handles the assignment (or vise versa).

0 Kudos
bbaker_tngeo
New Contributor III

Hi @JFarmer,

I thought about the assignment changing so I experimented with updating the Path Assignment before/after the Send Email Step, but both produced the same results. The issue was not that it was sending to the wrong user, it was that it was not showing any email in the To: line where the Arcade expression was specified, but it was sending to a CC that was just my email address as static text.

bbaker_tngeo_0-1678709779298.png

I was not getting anywhere with this so I ended up opening a case with Tech Support. There was not a clear answer to why the email was not populating. I can run the step as expected as an Administrator user type but any other user role will not evaluate the Arcade expression to populate the username's email address. The support tech suggested I review the Portal and Workflow Manager roles and privileges for clarity.

After that recommendation, I could not find any privileges within the Workflow Manager roles that would cause the issue I'm having. So, I started looking at the Portal roles. Most users using Workflow Manager are Publisher roles. So, starting with a using having an administrator role, I began turning off privileges until the step did not run successfully.

The conclusion I came to was that users without 1 Administrative privilege were not able to access a user's email address. When I enable the "Allow members to view full member account information within your portal" privilege, the step works successfully for the users (Custom role is Publisher with that admin privilege enabled for Workflow Manager users.

My assumption is that the users without this privilege enabled are not able to retrieve the user's email address, which is why the To: line in testing were showing up blank. I do not know if this issue is unique to the Portal I am using, which to my knowledge is a straightforward, federated Portal install, or this limitation might be more widespread.

bbaker_tngeo_1-1678710997467.png

0 Kudos
JFarmer
Esri Contributor

@bbaker_tngeo 

Thanks for the reply and sorry for the delay in mine.

What you are seeing here is correct. If the goal was to get the email address for a different user and the user running the step in Workflow Manager was not a Portal Admin, they would need this privilege. 

As a workaround, you could assign the Send Email step to a Portal Admin if that was a desire rather than having a custom Portal role. 

We'll work on better documenting this to help cut down on confusion in the future.

Jonathan

0 Kudos
bbaker_tngeo
New Contributor III

Thanks for the reply @JFarmer . 

I had already tried what you suggested (assigning the path to an admin before the Send Email step) but even when the step was set to Automatic, I was still having to advance the step as that admin user before it would run, which was defeating the purpose of the automation.

In this case, a supervisor of an Operations department (Publisher Role) is reviewing a project design from an Engineering department and then assigning it to an Operations Field Crew (Publisher, but could do everything they need to as a Data Editor, which would require another custom role). When the crew completes the work, an email is then sent back to Engineering to let them know it's ready for inspection. It seems to be working for all the users with that custom role and I did not see any adverse effect of allowing that privilege for those users. Let me know if you see any potential downsides with using a custom role.

 

Thanks for the follow-up!

Ben

0 Kudos
JFarmer
Esri Contributor

@bbaker_tngeo 

There aren't any issues on our side with using the custom role that I can think of, so I'd keep going that route since it sounds like it works for you guys.

Jonathan

SU00861536
New Contributor III

@JFarmer Can we apply Symbology in define location step? 

0 Kudos
JFarmer
Esri Contributor

Hi @SU00861536 

Symbology can't be applied within the Define Location step itself, no. But curious on your use case here? Are you looking for symbology within the web app or are you working in Pro? What's the end goal on your end?

0 Kudos
SU00861536
New Contributor III

User want to draw the polygon, applied some Symbology from front end at the time of creation of job. 

Once job is created, user will process the job in arcgis pro and once click on the job ..job defined location layer is added in ToC but applied Symbology which we applied at the time of creating the job is not showing.

 

In WFM defined location step user want to use own Symbology which applied at the time of job creation.

Please suggest some work around for this requirement.

0 Kudos
JFarmer
Esri Contributor

@SU00861536 

Just to make sure I understand the workflow here.

1. A user draws a polygon and symbolizes it (In Pro I assume? Or a web app?)

2. The use the geometry from that polygon as input to the Create Job action to use it to define the job location. Is this right?

3. In the workflow, there is an Open Pro Project Items step which opens a map and brings in the job location layer. This is where the symbology originally used doesn't show.

Where is the Define Location step used here? Or is the goal to use the Define Location step in Pro, apply symbology to that location defined, and then run the Open Pro Project Items step and still see that symbology?

0 Kudos