I have a custom ribbon button in each document library and when a user clicks it, I'd like to store some library-related data (URL, id ...) in a way that would make it available to a custom timer job. The timer job would then iterate the list of libraries and perform some operations on each of them. In other words, I'd like to give the user an option to enlist a document library for timer job processing. The timer job would need a table of data that looks something like this: Table What would be the best way to store this data for the timer job?

I won't need any complex queries. However, the amount of rows (libraries to process by the timer job) can go into several thousands (perhaps more). I'd like to allow enlisting of libraries to users who don't have admin rights. I don't want to be limited to a single web application data.

Here's what I've considered so far (based, among others, on this article):

  • I know that one option is to store everything in a custom database table. But this seems a bit too complex given that I won't be needing any special queries and I'd have to complicate things further with database permission settings.
  • I could create a custom list, but I've read bad things about its performance for even moderate-sized data. Also, I don't want users (sans perhaps the farm admin) to have the ability to view or edit the data - so I'd require some kind of hidden/read-only list which I could alter programmatically. Moreover, breaking the list into smaller parts might make sense (or would it?). Should I consider doing this?
  • other options such as SPPersistedObjects, property bags, SPWebApplication properties etc. require admin rights for writing, which means a normal user can't enlist a library for timer job processing.
  • (Just thinking aloud:) perhaps even deploying a custom data file (maybe even an embedded database) would make sense (not sure about the location though, maybe one of the mapped SP folders)? This would be easy to read/write using C#, but I'm not sure it it's a good idea.

What are my options?

  • 1
    You can easily Hide a List by setting a property SPList.Hidden, you can also consider deleting items from List once you complete the processing in Timer Job.. However list will reside in one of the site collections, I see you have multiple site collections which Timer Job will process.. Feb 17, 2014 at 12:47

2 Answers 2


SPWorkItemJobDefinition class is likely the best approach


You make a valid point that large list can be troublesome at times. Take a look at this link, it shows you how to handle large lists:
Also using CAML Query to access / refine your list is really fast.

As Arsalan Adam Khatri posted in a comment for you, you can easily hide a list.

To get you past your worry about the persisted objects, you can simply run your code in:

    using (SPSite site = new SPSite(web.Site.ID))
// implementation code here

I dont think you need to use a custom table for this. (Although it might be easier).

  • Wouldn't using SPSecurity.RunWithElevatedPrivileges elevate the user to site collection admin, while I'd require farm admin rights (the two not necessarily being the same)?
    – w128
    Feb 17, 2014 at 13:25
  • 1
    If you don't specify a user token it will be the app pool user. From the MSDN: A delegate method that is to run with elevated rights. This method runs under the Application Pool identity, which has site collection administrator privileges on all site collections hosted by that application pool. Feb 17, 2014 at 13:29
  • If I understand your question correctly you only need code to write to a List, for this the elevated privileges is fine. The user executing your TimerJob will just need some permission on the list in the sitecollection below to be able to read the data. Feb 17, 2014 at 13:38

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.