Solved

Users Unable to Access Tasks Assigned to Shared Mailbox

  • 26 April 2023
  • 4 replies
  • 249 views

Badge +2

Howdy,

 

I’m wondering if anyone has come across this issue before or might know a solution;

 

A handful of our workflows have assigned tasks that are sent to shared mailboxes:

 

 

However when the task email is received in the shared mailbox, and a person that has access to that shared mailbox, tries to open the task URL, they receive an access denied error in their web browser:

 

I presume this is because the task is assigned to the shared mailbox email, and not the user email, so access is rejected? 

We could get around this issue by disabling “Assignee Authentication” on the task itself, however we require assignee authentication as the approver details are captured for audit purposes.

 

Is this expected behaviour for shared mailboxes and tasks? Or is there a fix for allowing users to access a task that is sent to a shared mailbox?

icon

Best answer by SimonMuntz 27 April 2023, 08:18

View original

4 replies

Userlevel 6
Badge +22

Hi,

 

You have assumed correctly.  You would need to be logged in with the shared email address account to be able to approve the task.  Due to security reasons there is no workaround for this.

Badge +2

Hi,

 

You have assumed correctly.  You would need to be logged in with the shared email address account to be able to approve the task.  Due to security reasons there is no workaround for this.

 

Hmm that seems quite restrictive. Thanks for taking the time to respond.

Userlevel 6
Badge +22

Hi,

 

How about this workaround?
I assume the users of the shared mail box are added via an AD group.

If so you could query the AD group to get all the members and then loop through them and assign a task to each of them.

Badge +2

Hi,

 

How about this workaround?
I assume the users of the shared mail box are added via an AD group.

If so you could query the AD group to get all the members and then loop through them and assign a task to each of them.


Yes, we’ve been looking at this workaround. Seems like it may have to do.

Reply