on
RE:
clicking on a pinned visual should take user directly to that visual on the original report with the filers applied. This should be a built-in feature.
RE:
This feature is a huge miss on the MS side of things. It's a very common user experience in other competitive products, and needs to be something that's available soon, especially since Fabric doesn't allow for explicit user permissions to prevent Contributors from accidentally deleting something like a lakehouse on accident. We can't hamstring our users into just using view only permissions, in fear of them deleting something for good.
RE:
Hi Mukti, did you find a solution for this?I am facing the same with cash advance workflow, when trying to validate "An error has occurred. Exception occurred while executing action validate on Entity WorkflowWorkItem: The RefTableId (5077) must refer to either TrvExpTable (16365) or TrvExpTrans (20447). Exception has been thrown by the target of an invocation."
RE:
This is a much needed feature.
RE:
This is a great suggestion. I'm working on revising our permissions sets ahead of the security group enforcement at the end of this month and my users have personalizations that I'd like to copy to new profiles as well. It would be so much easier and less time consuming if I could just export an individuals personalizations and import them into the new profile. Or when we get a new users in a department, copy the personalizations to them.
RE:
Without the same support on charges in FnO and CE it's very hard to convince customers to use CE fully in the sales process
RE:
It is ridiculous collapsing control is not a thing yet. You got my vote.
RE:
This is a bug.The standard retention policy fails because no more than 10,000 records can be deleted at once when using the standard job queue. The codeunit 3997 - Retention Policy JQ expects a confirmation with a simple "yes" or "no." However, no user interaction is possible. I believe the issue can be resolved by removing the confirmation (See green) , allowing the job queue to automatically proceed with deleting the next 10,000 records.Please check the code of the codeunit:if Confirm(confirmRerunMsg, true, MaxNumberOfRecordsToDelete()) then ContinueWithRerun := true;
RE:
This is a bug.The standard retention policy fails because no more than 10,000 records can be deleted at once when using the standard job queue. The codeunit 3997 - Retention Policy JQ expects a confirmation with a simple "yes" or "no." However, no user interaction is possible. I believe the issue can be resolved by removing the confirmation (See green) , allowing the job queue to automatically proceed with deleting the next 10,000 records.Please check the code of the codeunit:if Confirm(confirmRerunMsg, true, MaxNumberOfRecordsToDelete()) then ContinueWithRerun := true;
RE:
Amazed this isn't supported yet, dataflows are the worst thing to lose or not have control over.