If you use the Content Organizer within a web under normal conditions, you don’t need to read further.
If you want to push Content Organizer to its limits — automating the entire pipeline from file ingestion to final routing — please continue.
Here are the pitfalls I encountered:
1. Timer Job Issues
a. Event receivers are disabled during timer job routing
A Drop-Off library ItemAdded event handler won’t fire if documents arrive via the Content Processing timer job. One-by-one pushes work fine, but a timer job push disables event receivers. Solution: use a workflow instead (see my previous post).
b. Large files and workflow race conditions
To work around the event receiver issue, we moved parsing logic into a workflow. The problem: while the timer job is still copying the file (it sets up two streams and does a final integrity check), the workflow can kick in before the copy is complete. With large files, this causes a “this item has already been changed” conflict error.
The result: the file ends up in the subsite Drop-Off library and stays in the root web Drop-Off folder — the delete of the source never happens. This doubling effect took us almost an hour to diagnose. Small files never triggered it.
2. Creating Content Rules Automatically
a. Don’t set RoutingAutoFolderProp via code
The “Automatic Folder Creation” field is read-only when set programmatically — SharePoint fills it in automatically. (I’m not 100% certain this is always the case; if I’m wrong, let me know.)
b. The RoutingConditionProperties field is misleading
The field type says “Multiple lines of text” but it actually stores only the column name — not the condition operator or value. Setting a condition via the GUI saves it; if you then edit the item programmatically, your condition disappears.
After extensive reflection (using a decompiler on Microsoft.SharePoint.dll), I found that SharePoint converts the condition into an XML structure:
<Conditions>
<Condition ColumnName="" condition="" value="" />
</Conditions>But what happens to this XML during rule evaluation still eludes me. The best approach: create one rule via the GUI, then inspect the list item to see the saved structure.
The other fields are straightforward — just map them to SPListItem properties during feature activation (scope: Web, with an activation dependency on the Content Organizer feature).
3. Creating the Connection via Code
See my dedicated post on SPOfficialFileHost.
4. Drop-Off Library Unique Permissions Bug
When checking files in the Drop-Off library without site collection admin rights, you can’t see all items. SharePoint sets unique permissions on items in the Drop-Off library — a bug that means site owners can’t see files that aren’t theirs. This is obviously problematic for automation. I’m still investigating a clean solution and will follow up.
These are my lessons learned (still learning) from Content Organizer in a non-standard environment. If you have a standard environment, let me know — you’d be the first! 😊