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? – Aziz Kabyshev Mar 15 '16 at 17:37
  • I have toggled the copyroleassignments value of true/false. Is that what you mean? – Tracy Mar 15 '16 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 – Aziz Kabyshev Mar 15 '16 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 Mar 16 '16 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... – Aziz Kabyshev Mar 16 '16 at 19:31

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, privacy policy and cookie policy

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