The title pretty much says it all. I'm getting an 'Unauthorized' response when I try to /breakroleinheritance on a Tasks list item in a 2013 workflow (inside an App Step). The strange thing is that I can run the command successfully in Fiddler, and I can /breakroleinheritance on items of other list types in 2013 workflows with no problem. I've tried the command in both an App Step and outside of an App Step, while kicking off the workflow with a site collection admin user - both with the same result.

Client is in O365. Is this just one of those non-documented oddities about Tasks? I would be super grateful if someone could try and duplicate this behavior and let me know how they fare.

Thanks! :-)

  • Have you tested if this behavior changes with different arguments combinations? Commented Mar 15, 2016 at 17:37
  • I have toggled the copyroleassignments value of true/false. Is that what you mean?
    – Tracy
    Commented Mar 15, 2016 at 18:52
  • 1
    I'm not able to reproduce this in my env. Could you please check problem statement and the link in accepted answer @ social.technet.microsoft.com/Forums/lync/en-US/…? Maybe that helps somehow Commented Mar 15, 2016 at 19:40
  • 1
    I've done exactly what you are trying to do with breaking role inheritance on tasks using REST. Just wanted to mention that there is no limitation in this regard. Just not sure exactly why it is not working for you. I'll try to repro this and get back to you, but hopefully this case will be solved by then so that you don't have to wait.
    – spguy
    Commented Mar 16, 2016 at 3:32
  • 1
    @Tracy yes, O365, Tasks list, 2013 WF. I wonder if you have another site collection in your tenant to test you workflow? Or maybe post a screenshot of WF... Commented Mar 16, 2016 at 19:31

1 Answer 1


I finally figured out my problems and thought I would note them here in case someone else encounters the same issues.

  1. First, a co-worker had overwritten my existing site wide app policy for workflows with a list-specific one by changing the scope attribute of the AppPermissionRequest and re-trusting it. It appears that rather than appending the policies, they get overwritten. This explains why I could get HTTP calls to work in one workflow (that was attached to my co-worker's list), and not my own.
  2. Second, when trying to re-create my own site wide app policy for workflows I misunderstood this tutorial who's picture indicates a URL with the app catalog site collection in it rather than the site where the workflow lives. Consequently, I was changing the policy in the app catalog site collection and not where it mattered.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.