Hi, please get in touch with the Partner Enablement team to discuss the design of this project! I assume that you are currently in build and not live yet? I am strongly suggesting this, on the basis of your example above. The alarm bell is to see individual employees in UD6. Adding employees into a dimension in OneStream is strongly advised against. This kind of information should be handled in solutions such as people planning or custom tables!
On the actual question, may I ask you to also share a screenshot of the row in the Cube View where you call the XFBR? Why do you say |MFUD1| does not work with an XFBR? I assume you are using UD1#Parent.Base in conjunction with |MFUD1|, which does indeed not work as the system checks the member filter on a row by row basis and can only return one member for each row (i.e. in the CV builder rows, not the ones you see in the report).
However, if you follow my strong advice, you need another approach anyway. Please reconsider your design and move employees out of the metadata!
Hello,
Thank you for your reply and recommendations.
" I assume you are using UD1#Parent.Base in conjunction with |MFUD1|, which does indeed not work as the system checks the member filter" is a correct assumption and is why I said "The issue with the XFBR is I can't use |MFUD1| to pass the current UD1 member".
