I understand, generally, how the Collect Feedback Workflow works, but I am not sure if it can work as a solution for this project.

My department's existing "Feedback Tool" used a custom list, here's how it worked:

  1. Someone - it could be the actual employee in question, their manager, or a designated third party - submits a "Feedback request" and identifies one user as the "subject" - the person about whom feedback is being solicited - and any number of users to be "evaluators" - people who will be asked to provide feedback about the subject.
  2. An email is sent to all of the evaluators, providing them with the name of the subject and a link to the NewForm.aspx of the feedback list, and instructs them to enter the subject's name in the first field and to answer a few open-ended questions about the subject in the remaining fields.
  3. A workflow runs on each submitted feedback form to import various other bits of data about the subject (e.g., job title, manager, etc.) into some hidden fields, to be used for filtering, etc.

This design had some issues:

  • The subject could be an employee of a variety of levels: director, manager, analyst, supervisor, or entry-level employee. Thus, their immediate superiors could likewise be in any of a number of levels. (For brevity, I'll use "manager" to refer generally to anyone who has subordinates.)
  • The intent was that any manager should be able to see feedback about their own direct reports, but that otherwise nobody should be able to see feedback about someone else (exception allowed for the feedback that they themselves have submitted about others). To be able to see feedback about oneself was not a hard requirement.
  • Secretaries were to be able to access all feedback about anyone except for other secretaries, so that they could compile reports for those less tech-savvy managers who are unfamiliar with SharePoint.
  • In order to allow feedback responses to come from any user, the list had to have Contribute access granted to everyone. So in order to meet the other requirements, filtered views were created, CSS/JS was added to pages throughout the site to hide SP UI components to prevent users from accessing e.g. the All Items view, links were put into audience-targeted web parts, etc.
    (I know - security by obscurity is no security. I wasn't around when this design was executed.)

So now we're trying to do this again, but with actual security this time.
My first thought was to use the "Users can only view and edit their own items" option, but this would make it very difficult to fulfill the "my direct reports" requirement.
We can't just give a manager the "Override List Behaviors" permission, as that would let them access everyone's feedback.
I suggested the use of secured folders within the list: a folder for each level of subjects, and then subfolders for each manager with subordinates at that level, granting each manager "Override List Behaviors" on their own folder. But it was thought that this would be too complex a permissions strategy to manage, that it would require too much manual maintenance. (I'm not sure that's true, but I haven't explored it further yet.)
I looked into using the "drop-off" feature as a way to automatically move the submitted feedback based on the subject's job title, but it appears that it's only available for document libraries, not for lists, and adding a document to the process would cause too great a reduction in usability.

So now I'm looking to see if better results could be achieved by using workflow tasks to collect the feedback, rather than straight-up list items. I'm thinking that maybe if the "view only my own items" setting is turned on, a manager can create an item in the list, assign feedback tasks on that item to the evaluators, and then their responses could be visible to the manager but not to one another.

Can the Collect Feedback Workflow do what I need? If not, is there a way to accomplish this with a custom workflow? (In case it matters, we're running SP2013, but only the 2010 workflow service is active.) Or, how close can I get?

For clarity, the absolute requirements are:

  • Anyone can provide feedback, regardless of their relative position to the subject
  • At least one of the following must be true:
    • Managers can view feedback about subjects whose user profiles list that manager in the "Manager" field
    • The user that requests feedback can view the feedback provided in response to that request
  • Except as provided above, no user can view feedback for which they are neither the subject nor the evaluator

And optional requirements include:

  • Secretaries can view feedback about any subject that is not a secretary (an exception to the last hard requirement)
  • Users can always view the feedback that they submitted


  • User Profile information is accurate and complete for everyone
  • SharePoint doesn't feel like the right solution for this. – Eric Alexander Feb 25 '17 at 15:11
  • @EricAlexander Honestly, I agree with you. Unfortunately, that is not a decision I have the authority to make, so unless/until the cost of my time as a developer begins to approach the cost of identifying, evaluating, and acquiring a third-party solution that's better-suited to the purpose, I'm stuck trying to solve it in SharePoint to the furthest extent that SP can fulfill. – Dan Henderson Feb 25 '17 at 20:10
  • It's just that SharePoint isn't going to give the security model you'd need to pull this off. The list level Item level permissions don't work that way, unique item level permissions (via breaking permissions inheritance) won't scale well. This means every item has to be readable by everyone fundamentally and you have to abstract over the top of it to present it like you want. Which means with a little digging, someone could see everything. – Eric Alexander Feb 25 '17 at 20:33
  • So, suppose we add the caveat that the manager would always have to be the person who initiates the feedback request. In that case, using the list setting on item-level permissions, would the evaluators have to have access to the list item, in order to be assigned a workflow task arising from it, and/or to complete said WF task? – Dan Henderson Feb 25 '17 at 20:48
  • If you customize the task form to include the list data, they would need to be able to see it. If you merged all of the list item data into the email body that get's sent out, then no, not necessarily. – Eric Alexander Feb 25 '17 at 20:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.