Problems with the Content Organizer: 10 shortcomings

The Content Organizer is one of the ECM features that got promoted to a global feature in SharePoint 2010, enabling it to be used in any site or context. It was already available in MOSS2007, but only within Record Centers.

I've used this feature in a couple of SharePoint 2010 projects and, unfortunately, it still had some problems. If you are building a new DMS, I would still definitely recommend looking at it, but not without first taking a look on the challenges I faced back then.
(...)

This feature is a core piece of functionality in Microsoft's Document Management strategy. It provides an easy way to upload documents to a central location and allows you to build a more complex architecture of information in your system, since users are not required to fully understand it or apply it. Be sure not to over-engineer or architect, usually less is more. Not requiring users to know where they need to upload files is a very big advantage, but you will need to have a good strategy regarding findability.

Here is the list of shortcomings:

1. Supported Content Types must be or inherit from Document, Page, Document Set, Rich Media Asset or Common Indicator Columns. Lists are not supported.
2. When a document is routed to the final location, if the target library has SharePoint Designer workflows to be started on item creation, they won't be triggered. The Application Pool account is used by the Content Organizer to do the routing and this account does not trigger workflows, by design.
3. The OOTB Rules only allow 6 conditions.
4. It doesn't check for the user permissions on the target library. The documents are routed using the System Account (privileged account) which means there isn't a security boundary around what goes where. On the other hand, the Create/Modified fields are not changed, making the actions easily traceable. This is particularly important to have in mind when choosing the overwriting model (see 2. below).
5. Adding Rule Managers is bugged: it doesn't allow groups.
6. Different behaviours when checking in a document either using the browser or a client application (i.e. Microsoft Word): when using the browser, the document gets routed immediately, while when using Microsoft Word it is not routed immediately - it will only be routed by the nightly Timer Job. There are other situations where the routing may not be immediate. You could change the nightly Timer Job schedule, but this can have side-effects. For instance, notification mails are sent by this Job, so a large volume of e-mails (rather than 1 a day) may be sent by the Content Organizer, which is not pleasant.
7. If you are using Lookup fields and OOTB rules, the fields can't have more that 20 values, otherwise the value in the condition doesn't get saved in the rule. The reason for this is that the edit field control for lookup fields changes depending if we have more or less than 20 options and the Content Organizer Rule List doesn't handle it correctly.
8. [Defect] If you use the Send To functionality to send documents back to the Drop Off Library to be re-routed, they can be deleted permanently. This will happen in the case where the document will be routed to the same location. The root issue is that the move operation in Send To is not atomic: it is a copy to the destination followed by a delete in the origin. This means it is not thread safe. If versioning is used for duplicate submissions, we have a problem. If while these 2 operations are being performed, the Content Organizer job actually does the routing in the meantime, the final result is: copy to Drop Off Library [Send To], routed to original library as a new version [Content Organizer], deleted from the original library - both versions! [Send To]. This defect may not always happen, but it is something to have in mind, it did happen to me! I've had similar behaviours in the past, on another setup, where Publishing a page directly (which corresponds to calling 2 actions in sequence: Submit for Approval + Approve) had conflicts with a workflow running in the background for auto-approving submissions if certain conditions were valid. Basically, the workflow would be processed after the submit action of the Publish and before the Approve, causing the page to get locked. In the case of the Content Organizer, the consequences are far more dangerous.
9. [Defect] If you have try to develop customizations on top of the Drop Off Library, such as an Event Receiver or Workflow, that creates a new version of the document (an example would be automatic tagging), and check it in as System Account (to identify it as a system change), the Content Organizer Event Receivers can create a new version with modified permissions (System Account + Rule Managers) and the Modified By field will actually be set to the first Content Organizer Rule Manager in the list (!!). I have not experienced this in every Content Organizer setup, so I am guessing this may be dependent on a specific set of configurations or SharePoint version to happen.
10. There is a feature called "E-mail Integration with Content Organizer", but according to some people's investigation (and Microsoft feedback) this is only a legacy for Exchange 2007 and should not be used for this purpose in SPS2010 (see here).

Some other important points to notice:

1. One of the options provided is to force the usage of the Drop Off Library. This enforcing will only happen on libraries that are the target of a rule. Also, if users use the Windows Explorer to upload the files, this enforcing will not happen.
2. Be very aware of the overwriting documents option. If you do not have versioning enabled in the destination library, if you upload a document with the same name, it can permanently overwrite the existing document. In a large system, with versioning enabled, it is also unsettling for the users to have the Content Organizer routing document from the Drop Off Library to a Destination Library as a new version. If it was just an accidental duplicate naming, users will certainly be confused and can even lost track of the previous document.
3. Unique permissions when a document does not match any rule: only the Creator and the Rule Managers will have permissions to see the document. I believe this is a good thing, but consider this behaviour if you have the idea of implementing any workflow (or similar) on the Drop Off Library.
4. Content Types must be defined on the Site Collection / Site level, otherwise they can't be used on the configuration. This actually makes some sense, you shouldn't be defining your Content Types on library / list level anyway.

I haven't really been able to validate these against SharePoint 2013 yet, but it is something I'd like to do next. For the moment, this is the list I compiled some time ago, but never decided to publish until now. Some of these issues may have been fixed by Service Packs / CUs, or may only happen under very specific situations, so they are just warnings. If you plan on using the Content Organizer, proceed with caution!