Why do email notifications cause entire workflows to fail when one user is disabled or deleted?

one option is to handle it on D/Exchange side.

you could create an AD group, shared mailbox or a mail distribution list.

that approach is suffucient if you're only sending notification mails to the memebers.

if you need to assign tasks to the members, create a sharepoint group and maintain currently active users there. 

Both of those options I see working in static, small department, cases.

All of my workflows pull in approvers dynamically from a master list(or multiple), based off which department or building you select on the form. Then routing is determined in the workflow based off options you chose. Some having state machines with 10+ branches. Then notifications at the end are designed to be sent to the people who were involved in the workflow.

I don't have many workflows that are designed for the same few people to receive notifications for every item submitted on a list. Very few could have static groups to target notifications.

This isn't secluded to just notifications either. The same problem exists with the set permissions action. 

Both of those options I see working in static, small department, cases.

I don't think so at all :)
I would rather see it opposite: the complex workflow/process you need to manage, the easier you can do it with use of role-groups. complex and/or long(er) running workflows are much prone to these user validity/responsibility problems.

All of my workflows pull in approvers dynamically from a master list(or multiple), based off which department or building you select on the form.

just like you keep there evidence of approvers (users), you could keep the evidence of above mentioned groups.

Then notifications at the end are designed to be sent to the people who were involved in the workflow.

if you need to track exact users involved (eg. task approvers) you could save them during the workflow in a dedicated list field or list, or you could could query them from task list or version history - depends what exactly you need.

The same problem exists with the set permissions action.

that's the exact scenario where groups are better approach.

Maybe I'm not understanding, or I'm not explaining correctly. 

Of course it would be better to have a group of people to set permissions or notifications to. The problem I have is that every workflow contains a completely different group of people.

Let's say the refund workflow has 9 approvals. One of the options on the form is a building. We have 80 buildings. Each building having it's own group of 9 approvers. The last 3 approvers may or may not be involved on the workflow at all, depending on what type of refund. Approvers 5 and 6 may not be in the workflow depending on the amount the refund is for.

So the solution here, instead of the ability to just skip erroneous names, is to build and maintain 1,680 different but similar groups? 

The only "solution" I've come up with so far is to build an escalation path of conditions checking each and every account I use anywhere ever. And since check if a valid user errors when checking an empty field(while I feel that should just return a false, not a critical error making the WF fail), you have to double up on that to first check if it's empty. 

This is where I feel like I'm missing something obvious. I would imagine something as beautifully crafted as Nintex has a better solution in mind, but I haven't found it yet.

Let's say the refund workflow has 9 approvals. One of the options on the form is a building. We have 80 buildings. Each building having it's own group of 9 approvers. The last 3 approvers may or may not be involved on the workflow at all, depending on what type of refund. Approvers 5 and 6 may not be in the workflow depending on the amount the refund is for.

so to understand it correctly, you have 9 approval steps and 1 appover per each step? and some approval steps may or need not be executed based on various conditions.

ie. something like SM with 9 states/branches with an approval task in each branch, where some branches are gone through but some not? 

=> so IMHO 9 groups like Approvers_Step1 .. Approvers_Step9 should be sufficient.

futher, you need to run above approval for 80 buildings where set of approvers for each of them is different. that would give me 80*9=720 (unique) appovers or groups alltogether. (not sure how you come to 1680)

that may still sound too many at first...

but I assume you anyway need to maintain that matrix of all the approvers per building and per approval step. 

if you managed it over groups, of course you would need to create all those groups and configure them in the matrix. but that would be just one time job. your current effort to maintain the matrix would have moved to effort to maintain respective responsible approvers in single groups. IMHO that's quite similar amount of effort but that would keep you from problems when some approver(s) leave or change the role.

The only "solution" I've come up with so far is to build an escalation path of conditions checking each and every account I use anywhere ever. And since check if a valid user errors when checking an empty field(while I feel that should just return a false, not a critical error making the WF fail), you have to double up on that to first check if it's empty. 

here I agree with you, that's quite weird behavior of the people validity check. empty value should be considered as invalid user and shouldn't fail the workflow.

so if you means it doubles number of logical checks then you're right. but if you mean it need to double number of workflow actions to perform all the checks, then that's not needed. you can check for both people variable/field emptyness and validity with the same workflow action. just make sure check for emptyness is very first action.

futher, you need to run above approval for 80 buildings where set of approvers for each of them is different. that would give me 80*9=720 (unique) appovers or groups alltogether. (not sure how you come to 1680)

You're missing where steps 5 and 6 may/not be involved. I'm not the best with combinatorics, but I believe it's 80(buildings)*21(possible outcomes). Regardless, it's way too many groups to manage. 

Currently there's a large list where I'm keeping track of these individual people. So every workflow starts with a query for the approvers listed in all the positions for the selected building. 

if you managed it over groups, of course you would need to create all those groups and configure them in the matrix. but that would be just one time job. your current effort to maintain the matrix would have moved to effort to maintain respective responsible approvers in single groups. IMHO that's quite similar amount of effort but that would keep you from problems when some approver(s) leave or change the role.

Hmm, that does not seem to be the same amount of work. That's managing 1680 people in completely separate groups. That's much different than managing a single list that has 1680 fields. It's all on one screen, or "matrix" as you've called it. managing a single group for each is a lot more effort. Just selecting the SP group and adding in the extra person is a few screens and probably double the amount of clicking/loading. It may sound pedantic, but it does take extra time/effort.

so if you means it doubles number of logical checks then you're right. but if you mean it need to double number of workflow actions to perform all the checks, then that's not needed. you can check for both people variable/field emptyness and validity with the same workflow action. just make sure check for emptyness is very first action.

I thought I had tried that, but it's possible I had check for empty after the check for valid user. I'll have to revisit that.

One of the ways we were going to try and get around this was through AD groups. We already have an automated process that assigns security groups to people. We went through and assigned each person a group. Tasks assigning worked fine. Unfortunately, the notifications wouldn't work with an AD group so we stuck with the giant matrix of specific people.

You're missing where steps 5 and 6 may/not be involved. I'm not the best with combinatorics, but I believe it's 80(buildings)*21(possible outcomes). Regardless, it's way too many groups to manage. 

maybe I really miss something, but why would approvals that are not executed )sometimes) would multiply number of groups?

you can not count number of outcomes, but rather number of approval steps/actions.

Hmm, that does not seem to be the same amount of work.... 

of course, that's matter of point of view :)

if assigning direct users, when you need to change a user in a specific approval step/role, you have to take into account as well effort to investigate all the runnig tasks/workflows for a user being removed and take all the needed corrective actions so that tasks are moved to new user.

if you used groups, that's not needed at all.

futher, I can imagine managing users within groups could be automated quite easily.

eg. if you named your groups with a common pattern (eg. Building##_AprovalStep##) you wouldn't need a mapping list that assigns groups to combinations of building and approval step at all. you could build group name within the workflow dynamically.

adding/removing users to a group could be automated (or at lest made easier) with eg. a site workflow with customized start form. on the start form you would ask for inputs like building number/ID, approval step, user, add/delete option,etc and workflow would take care to perform respective action. if a group for a given combinations of inputs didn't exist, it could as well create it autmatically in background. so you wouldn't even need to know how many groups are there, and it would automatically expand if yoi added further buildings and/or approval steps.   

We have a similar problem with warehouse processes which have 4-6 steps and every step has 4-7 users to inform. Using distribution lists is very uggly to maintain due to some company procedure in Asia.

One process can take several weeks, so it can easily happen that a user has left.

People for every process are different depending on the Warehouse area involved.

And this is the basic trick. We have SharePoint lists to be maintained for every Warehouse Area and Process Step. Before the next step is started, you can reread the most current selection for this process step and Warehouse area. This way you do not automatically run into an error.

This solution will only work if you do not need individual user settings for every item. If this is the case, you have to invest into checking procedures.