Scenario
I have a cube (tabular model)
It contains a list of Customers, and a measure Revenue.
The Customer table has a column Client Account Manager.
I will have a report which points to this default perspective, and the Security Role will apply Row Level Security showing only the Client Account Manager their Revenue, for their Customers. Simple.

For Account Managers & Non-account managers, I also want them to be able to see the revenue for any Customer, even if it is not their own, but I don’t want them to be able to write a report (or remove a filter), and sum the Revenue for each of the Client Account Managers.

I only ever want them to be able to return 1 Customer at a time. (I realize if they ran the report for all 20 customers an Account Manager manages they could do the sums themselves)

So, I can’t see how to do this now, but if I had the following enhancement, it would allow me to use the same cube, with different perspective.

I want to create a perspective on the same cube, without Client Account Manager Column. So, the user cannot select this field.
Given I only ever want them to be able to see 1 customer at a time a Perspective Level Required Filter would enable this for me, without the need to build a second cube.

Azure Analysis services "Allow access from the Power BI Service" (enablePowerBIService: true) firewall option does not include connexions initiated from Power Bi Premium Paginated Reports. The only workaround is to allow regions IP ranges from the list : https://www.microsoft.com/en-us/download/details.aspx?id=56519

A Premium service should include such feature :

- adding hundreds IPs to an AAS engine is a lenghty operation particularly when you have many engines to manage

- custom tracking has to be done to ensure having the latest list, with automated deployment keep engines accessible

- allowing hundreds of IPs when just 2 at a time is not the best target for security point of view

- having an integrated solution is often more reliable and future proof

The possibility to select the premium capacity from a tenant would be a killer feature (PBI tenant not always the same as the AAS engine).

Current Row Level Security(RLS) works that when you filter on a dimension, the related fact tables get filtered. While this is a good features, sometimes you have to deal with more complex variants.

Example: Lets say I have 2 dimensions, product and customers, and 1 fact table, sales.

Every user is allowed to see all rows that is connected through the product or customer dimension. However, when they are looking only at the dimensions, they should only see their own products and customer.

Both can be solved, but not in the same scenario.

Scenario 1: See rows either attached to your customer or product:
You you have RLS on the fact table with a OR clause and you can see all the rows that have either your product OR customer value assigned to it. However you can see all the rows of the dimension. Setting RLS direction to both doesnt work as you are only allowed to do this on 1 table.

Scenario 2: Only see dimension rows that are assigned to you.
Setting RLS on the dimension solves this, but then you are only allowed to see the combination of your customer AND product key. You cannot see the rows that only have your customer OR only your product.

Workaround: Creating a massive many to many bridge table that impacts the performance significantly. Bridge tables stores every possible combination and is also linked with a special key to the fact table.

Proposed solution: Being able to disable Row Level Security for certain relations. Relation stays active for normal slicing and dicing. Rows in the fact that either have no valid product or customer, can have their dimension value set to (NULL), if RLS is also active on the dimension table itself.

this is a general suggestion to the DAX/Analysis Services. Based on what I thought calculation groups would bring.

I thought selectedmeasure() would work like, Isfiltered().. so you could somehow choose a calculation and then apply a measure in power bi.

So i would make a YTD Calculation "group".. and then I could choose any measure in power bi and apply it to. So you don't have to create Sales YTD, Quantity YTD, OrderIntake YTD etc etc etc.

you would simply have a "group" function called YTD. and then it could function with all the measures. to reduce the insane amount of "dublicate" measures you have today which all use the same logic, just on different base measures. (sales, orders, Qty etc)

Then in Power Bi, it could then work like a "hiarchy" of sorts.. so it would work in KPI cards etc. so you would first drag, the calculation group/type into values. and it would then accept you draged any measure on top of it, and show it like hiarichie are showed.. it would then know, THAT was the selected measure.

Then you could reduce

Sales
Sales YTD
Sales LY
Orders
Orders YTD
Orders LY
QTY
QTY YTD
QTY LY

To

Measures:
Sales
Orders
QTY

Calculation type/group:
YTD
LY

in this small example, we get an almost 50% reduction in measures on the server. And the more different measures. the bigger the reduction.

When an Azure Analysis Services instance is Paused, any deployment of an Azure Resource Manager Template that includes the Azure Analysis Services instance fail with the error "The server is currently being updated. Please try again later.".

This happens even if the exact same configuration is applied to the Azure Analysis Services instance and has the potential to break CI/CD pipelines as a result.

Azure should allow Analysis Services to be "updated" by Resource Manager Templates while in the Paused state for configuration that is not dependent upon a running instance.

Other Azure resources like Stream Analytics and Synapse Analytics allow this exact scenario.