@shreyak.garg We too are facing the same issue. Just to further shortlist the two differences between you and the user - in our case both the user and the WA have SSO enabled. So, essentially, everything else being equal - being WA seems to resolve this issue.
Please do update this thread in case you happen to find the cause/solution.
@shreyak.gargIf I'm understanding you correctly; you have a numbered list with selective access enabled. There are also orphans in the numbered list. The action which is causing errors is mapping parents to these orphans.
Anaplan correctly denies access to orphans in a list with selective access enabled to non-WSA users. This is why the action is causing the error.
I suggest either mapping the parent in the same action that is currently creating the orphans. Or alternatively, the orphans being created currently should be mapped to a temporary dummy parent. This will allow all users access to the orphans and the last action should successfully remap the 'orphan' to the desired parent
Is it possible that the user running the action does not have access to the parent that the child is currently at.
The user I'm testing with does not have access to P3, the parent of C6 and is also not a WSA
When this user runs an action to update the parent of C6 as below he will receive the "Unauthorized to move this entity" error
The difference between my original answer and this is that the problem child is not because it is an orphan but because it is currently mapped to a parent which the user cannot access. When the user tries to remap any child to any other parent, irrespective of whether he has access to the destination parent, he will be unauthorized to make the change.
I just helped a customer dealing with this same issue, so I figured I would give a general overview of what is happening in this situation. Hopefully this resolves all current and future questions people have.
There are two main factors at play in this situation:
1. Why it does not happen to Workspace Admins:
During an import, Workspace Admins have a special ability to affectively 'ignore' Selective Access on the target. This is intended - there are situations in which a Workspace Admin should have limited view access (with sensitive data like HR salary information) however the base data still needs to be imported. A user does not have this ability, so in general if they try to import items without the correct Selective Access, those items will fail.
2. What is happening that causes this error for Users:
This error and ones like it are completely caused by List level Selective Access. As a test, if you remove Selective Access from all lists in your model then have the user attempt the action, they will be guaranteed to not see this error. But obviously Selective Access is necessary, so here is how to understand what is happening:
This error can occur when creating a new item or modifying existing ones: A. "You are not authorised to move item to parent: <X>" - when the Parent specified for the parent is one that the user does not have Selective Access to.
These errors only occur when the item already exists: B. "You are not authorised to update this entity" - when they do not have Selective Access to the existing item and are trying to change something other than Parent. C. "You are not authorised to move this entity" (the one in question in this post) - when they do not have Selective Access to the existing item and are trying to change the Parent value.
The lack of Selective Access described here can be caused by not having access to the item itself, or the item's parent, or if the item has no parent.
Even though we cannot obtain the same error exactly as a Workspace Admin (due to reason #1), we can still troubleshoot - set your Selective Access to be the same as the User, and view the list dimension somewhere in a module or dashboard (NOT in the settings area, as this will display all items regardless of Selective Access). You will not be able to see whatever item or parent the user is attempting to update. That is the root cause of the issue - figure out how to either A. give access to the appropriate item, or B. not include that item in the users import.
One thing to note: The last two errors cannot occur when creating a new item. If you thought that the item did not exist or had been deleted or something but the non Admin user is receiving this error, then go to the settings area and search the list for that item - what is most likely is that the item still exists and has become an orphan item because the parent was deleted. They are displayed at the very bottom of the item list, and do not role up to the 'Top Level' item. If Selective Access is in place then end users will not be able to modify records that do not have Parents in a hierarchy, causing the error. In this case, it may be good to have an automated 'Delete from List' action that removes any objects that do not have parents or something similar.
As a summary - the error message is not an Anaplan bug but intended behavior when Users try to update or move items to which they do not have Selective Access. A Workspace Admin will not see this error because they have an intended exception to standard access rules when running imports into lists with Selective Access.
That should help clarify this issue for others encountering it. If you are still encountering issues or confusion with this error, please open an Anaplan support ticket and include a link to this article/comment as reference.