PAW - Subset behavior

Guest: a selector with an MDX that looks at the Global Settings cube, is not the solution. The MDX is correct but even after a refresh of the PAW dashboard the previouly selected element remains visible. Not the element at index 1 of the subset. Someone has to go to each sheet in each dashboard to have it correct, a ridiculous waste of time and effort. Please IBM, have this corrected, it is blocking customers in a lot of instances ! Maybe an optiobal toggle to take an element index like SUBNM ?

Responding with a late comment, but perhaps this is useful.
on the first point about managing the member that is shown from a subset - the most common approach I see for this use case is to utilize a lookup. By lookup I mean specifying in an MDX expression to show a lookup from a "Global Settings" cube where many Finance cycle members (ex: Current Year, Current Month, Forecast Start Month) are maintained for the model. This would avoid an empty subset result. This would also avoid a dependence on Index which in my opinion is not best practice since indexing is not always tightly controlled.

Hello Stuart,

Thanks for your reply. I don't hink it is the right place for feed back answer because the lack of visibility.

Anyway I understand your point, it can be very confortable to not change a default value all the time. However there is many cases where it is. Typically changing month or budget phase in financial application is the same requirement in pretty much all application as explained in PA community here.

We manage to have a workaround by saving books with an out of scope element but it means to create or keep dummy members for each book modifications...

A second linked subject is error popup. We really like to be able to desactivate them. We have some cases where we want a blank selection, for example when it is a salary selection (pretty impossible to put any default value here). That is not only anoying but really confusing for users. They think something wrong happend or the tool is broken... I have the feeling it would not be hard to add an option to desactivate them.

Best Regards,

I can reproduce the behaviour described in the description. However, I'm not sure if this is something we want to change. The view in Workspace remembers which subset is used for each hierarchy on the title axis of the view. It also tracks the currently selected member in the WHERE clause of the MDX statement for each hierarchy on the title axis. I expect the natural expectation for many uses cases to be the member remains the same, when possible, even if the members in the set has changed. We might consider how member context could be passed to views through synchronization functionality.

I've set this idea to under review while we do additional investigation. Additional comments about the use cases that require the member to change based on index might help.