Unable to update app until users are removed: 'groups have failed validation'

[TM_Visual]

This is an on-going minor problem that has affected my team for a long time. I can add a new user to an app audience (or prior to that, the access list) and update the app.

However if I change the user list and one of the existing users in that audience has left the organisation, the app will not update.  This is because their account is deactivated. The error message is:

The following groups have failed validation : "12345678@company.com"; "12345378@company.com"; "56345678@company.com"; "12341178@company.com"; "12340088@company.com"

To publish the app with new users the error must be closed, then the users manually removed from the audience by finding their name in the access list.

This is awkward for several reasons:

1. There are often many users that have left the organisation and need to be processed in this way.

2. When an app has a large distribution list to scroll through it takes time to find the correct person.

3. All users have an underlying identity in the format 12345678@company.com. We also have an email identity as name.firstname@company.com . The error message shows the ID number@ email address of staff, but the audience lists their name.surname@ email address . The ID numbers are not known. We have had to develop another system to retrieve staff names from the ID number that is shown. 

The names are obviously being linked up somewhere in Power BI's identity system, as the error message IDnumber@company.com email addresses are listed in  the alphabetical order of the name.surname@company.com of the users!

I believe that this issue is likely due to this identity system used by my org.

Perhaps Microsoft's identity management system is viewing each of our users as their own 'group'. 

We are able to assign access to groups of users, but we don't want to control all access via the group system, both because there are additional steps and because groups can't capture the complexity of access rights required.

My ideas for solutions to this problem include:

- Allowing apps to be published despite invalid users.

- Providing an option for users publishing an app to remove invalid groups or users automatically.

- Display invalid accounts at the top of the list of users so it is convenient to remove them.

- Reconciling the identities of single user groups, or however my organisation is likely to be using the identity system.

[v-xiaoyan-msft]

Hi @TM_Visual ,

Based on the above information, this issue is complex which may need to collect log files for further troubleshooting. Since community support engineers don't have that access, I would suggest opening a Support Ticket. If you are a Power BI Pro or Fabric licensee, you can create a support ticket for free and a dedicated Microsoft engineer will come to solve the problem for you. 
It would be great if you continue to share in this issue to help others with similar problems after you know the root cause or solution.

The link of Power BI Support: Support | Microsoft Power BI

For how to create a support ticket, please refer to How to create a support ticket in Power BI - Microsoft Power BI Community

Best Regards,
Community Support Team _ Caitlyn

[TM_Visual]

I have raised this as a support ticket. The outcome after speaking to support is basically "tough luck, that's how it works".

An idea has been opened to broadly change how access is removed from larger numbers of users, but it is rather general.

So although the Power BI access system is built around individuals requesting access and being granted on a per-person basis, the best solution is to reject all individual requests and only use groups set up using another part of Office 365. 😞

If anyone else is having this issue, the only solution I can recommend is using groups and otherwise putting up with the inconvenience.

If anyone in product development reads this, the (possibly) lowest effort change that could be made would be to make the "can't update app until these groups are removed" error message contain the full human names as well as the names of underlying accounts, or otherwise flag the invalid accounts to make them easier to spot.