Good day, everyone.

We are planning to implement a discussion-board based ticketing system on SharePoint Online 2013.

One of the important functional requirements would be restricting access to tickets based on the category it was posted under (e.g. IT, Human Resources), such that only the original poster and the assigned group of personnel can view/reply to tickets for that category.

There are two methods that we have identified:

  1. Using a workflow to change the permissions of each ticket (Discussion) upon creation based on an added "Category" column, or
  2. Splitting the system into different boards based on category, with only the assigned group of personnel getting full access (everyone else can only view/reply to tickets they had created).

Our Questions:

  • If we go with method #1, we would effectively be implementing item-level permissions for each ticket posted. What would be the limitations of this approach?
  • If we go with method #2, we would need to implement 'combined' views for certain functionalities, such as allowing a user to view tickets they have posted across multiple/all categories (forums). What would be the best way of doing this?
  • What other suitable alternatives are there to #1 (permissions for each ticket) and #2 (separate forums for each category)?

For reference, we are mostly restricted to out-of-the-box SharePoint Online 2013 and SharePoint Designer 2013.

Thanks in advance for your help.

2 Answers 2


Ticketing system is usually necessary if there are many tickets. But putting many items in one SharePoint list is usually not a very good idea, because after reaching 5k limit, it will become more and more difficult to work with this list, especially programmatically.

Also there's a limit of how much unique permissions can be in a list.

Distributed approach

I would recommend considering a distributed approach. So for example, create a special list on every My Site, and setup folders for Categories in this list, providing unique permissions for each folder. It can be done e.g. via a simple CSOM console application. Later similar app can be used to update the lists, in case if new Category appears, or something like that.

Once you have all those special lists on My Sites, one list per user, you effectively got rid of any limits-related issues.

Now, to collect all these items and show them in one place, just use search. Search respects permissions, so no problems here. You can configure filters for different categories. Also, you can customize search output if you need. And all these refinement features will come in handy too, I think.

The main spike here with this distributed approach is that search can sometimes lag a little bit. The delay should usually be somewhere between 5 and 15 minutes, but please try it yourself for several days and see if it is OK. Because in certain situations, I read that people had experienced up to 1-day delays.

Provider-hosted app approach

Another approach would be to create a provider-hosted app. Provider-hosted app can do event receivers, so permissions are much easier to manage.

But I would recommend thinking even further. With a provider-hosted app, you can consider storing the information in external DB and displaying it via a completely custom interface. In this case, you can guarantee quality of the system to your customers, and it will be really fast. Solution based on MS SQL can directly handle relatively huge amounts of data, processing and filtering millions of records with only milliseconds of delay...

Solution will be easily transferrable to any other platform, because it only depends upon SharePoint authentication system.

Modern web interfaces are very easy to create. There are tons of js libraries like KnockoutJs and AngularJs for modern-looking, dynamic UIs; you have Bootstrap and Font Awesome and similar toolkits for building your solution with tested, reliable, good-looking and mobile-ready blocks.

SharePoint is unfortunately notorious for providing spikes in most unexpected places, so relying on completely custom solution additionally allows you to provide relatively very precise estimations for when solution will be ready.

And finally, I cannot resist mentioning, that apps and provider-hosted apps in particular, are actually the recommended by Microsoft way of doing things. "The right way", if you will :)

  • Thank you for your detailed reply! As mentioned, we are limited to OOTB SharePoint Online/Designer, so provider-hosted apps would not be feasible. WRT My Site approach - so discussions/tickets are stored in a list of folders within each My Site, and pulled to the ticketing system as needed (limited to user/support staff)? There is also the issue of adding folders, as the ticketing admin would need access to said list. I had mentioned having forums for each category (#2), and limiting normal users to viewing their own tickets. Will implementing permissions like this affect performance later?
    – kwgoh
    Commented Aug 28, 2014 at 1:20
  • To be more exact, for method #2 in my 1st post, we will have two groups of users for each forum/category - a small group of Support users who have contribute access, and a group of all users in the tenancy who can only view/edit/reply to their own tickets (as per blogs.msdn.com/b/officeapps/archive/2013/09/25/…). Would implementing permissions in such a fashion count as item-level instead of list-level permissions? And how will this affect performance when the system has many tickets?
    – kwgoh
    Commented Aug 28, 2014 at 8:12
  • @kwgoh did you resolve your issue? if yes how have you done it? i have meerly the same need and i wonder wich approach you fellow... And why not work with WorkFlows? Commented Sep 15, 2014 at 8:44

just as a reminder and a comment: the typical 2013 sharepoint community (message board) allows only one category per thread unlike the categories in blog posts that can be many. This is surely an improvement Microsoft can get their hands on in the near future.

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.