You are not authorised to move this entity


Hi all,


I am receiving an error with one of the numbered lists - "You are not authorised to move this entity".




ONLY non- workspace admins are getting this error.


They are able to add items to the list but they cannot put the Parent against the Parent field. 


I have checked the action and the Parent field is being correctly mapped in the action - as mentioned in this thread.


The user has access to the source module view and is able to see the data that is being used for Parent mapping. The user also has access to the list in Roles -> List section and the Roles-> Actions section for the action being run.


Also, this numbered list has a parent/child relationship and the top ancestor list in this chain has selective access. The user has Total Company access WRITE access to this ancestor (Top level element) list.


Can anyone identify the issue if they have seen this before?



  • Hi @shreyak.garg 


    Is the parent that is being mapped a new parent that is being created or an already existing one? 


    Have you tried to split the multiple actions in one process into more smaller processes? 





  • @shreyak.garg 

    It is likely to be something to do with selective access on the Parent, but the best bet here is to log a support call so they can look into the specifics

    If you get an answer, could you post the resolution/reason here?



  • Hi @shreyak.garg 


    I think this error is being caused because non-workspace admins cannot create orphans in the list. Basically the last action in your process is creating members in the list which do not have a parent assigned to it

    Can you please check if the members being added to the numbered list which are causing errors have the valid parent correctly mapped




  • Hi @anirudh,


    The non-workspace admins are able to create list items using the last action in the screenshot (i.e. orphans are being created). However, the orphans are supposed to land under their parent as part of the same action which is not happening. The parent does exist and we are using CODE of the parent for the mapping in this child list action.


    Like I said, I being a workspace admin can put the parent in the parent field (using the action) however when a user runs the same action, the action creates list items but doesn't fold into the parent.

  • Hi @usman.zia 


    I have actually tried removing the process all together and let the user run that single action from a dashboard button.


    It still leads to the same error.


    I gave the user FULL ACCESS instead of the role and it still doesn't work.


    Only Workspace admins can perform it (Full Access or Role Access both).



  • @shreyak.garg ,


    Try this, with the same access as the user (so take your WSA off), go to the module, open the view and see if the parent is supplied in the line item.  If it is, then you most likely have a security issue where the WSA has access but the users don't.  If the parent is not defined in the line item, then you have could have a different security issue at the module level or Selective Access like David stated above.


    Hope this helps,


  • Hi @rob_marshall 


    Thanks for the comment.


    I have tried this as well. I opened the module/view on the user's account to see if they are seeing data in all the line items needed. He was able to see all that's needed to fold the list.

  • @shreyak.garg ,


    Ok, now that you know the information is correct, look under Users and go to the Roles-> List tab and see if their role is checked for that list.  Lastly, any Selective Access on the list?



  • Hi,


    Yes, they have all the Roles-> List, Roles-> Module access.


    In fact, it doesn't even work with him having FULL ACCESS.


    It has something to do with Workspace Admin OR Single Sign On. These two are the only things that are different between the user and myself.

  • @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


    Hope this helps!




  • AdamT

    Hey Shreyak


    Is this happening to ALL elements that are needing a parent reassignment, or only specific items?  Could you create a view with a single record that has the issue and test it?


    Also, have you tried turning off selective access altogether and tested it?

  • Hi Adam,


    Is this happening to ALL elements that are needing a parent reassignment, or only specific items? 

    Yes, all of the ~1100 list items get created as orphans, with their properties populated correctly except for the PARENT field.


    Could you create a view with a single record that has the issue and test it?

    Yes, this could be tested. We did test with a new view and action (with all items) and it didn't work.


    Also, have you tried turning off selective access altogether and tested it?

    Selective access is at one of the ancestor lists - #Project (very high level). We didn't remove the selective access at the Project level.

  • Hi all,

    I am getting the same error.

    I have four hierarchical lists with the top list having selective access.

    I am trying to import the list from a module as a non WSA. I have set the role to full access and given write access to top level item of the parent list.

    When i run the process the first list(top parent) gets imported. However the next 3 subsequent lists throw an error "You are not authorized to move this entity".

    The action used to import the child lists have parents mapped to them in the same action.

    But still i am getting the same error for all the next 3 lists(child lists)



    Thanks in advance

  • Hi Preethi,


    The steps you have mentioned look identical to the issue we had.


    To my knowledge, it is still an unresolved issue. I will confirm with the support team if there has been further progress.

  • @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.
  • @prakashnishtala - We had tried to check with both SSO and non-SSO for the WA whereas the user was always SSO enabled. The error still persisted.

    This was for a client and I don't think it has been resolved yet.
  • @shreyak.garg Revisiting this thread to check if you were able to get any solution for this. It is still an issue for us as of now.

  • Hi Prakash,


    Is it possible that the user running the action does not have access to the parent that the child is currently at.

    Example here:



    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.




  • Hi @shreyak.garg 


    We have a situation where we ended up in the same point as in your last comment - after going through all the steps mentioned above, everything seems to be mapped correctly and the only difference between users getting the error or not is the workspace admin selection.


    Is there another reason that you were able to identify in your process?


    Thank you!