Introduction to Sitecore SCS scopes

Choosing the wrong scope is a common way that developers accidentally break a production environment or bloat their Git repository. Sitecore Content Serialization (SCS) isn't "all or nothing", you have options when it comes to choosing what gets serialized. We'll dive into the difference between ItemAndChildren and ItemAndDescendants (the default value) and discuss which option is best for your specific needs and when to use Ignored. It's important to understand all of the options to avoid deployment accidents which can lead to overwriting content or performance bottlenecks.

Deep dive: 'ItemAndChildren'

ItemAndChildren serializes the parent item and it's immediate children only. You would choose this option when you only care about the top-level structure, as it avoids serializing deeply nested unnecessary items. It helps to keep serialization files organized and relevant while excluding unnecessary content. Performance Impact: High efficiency; it limits the crawler's depth.

When to use it:

• Specific Template Sets: When you want to serialize a template folder and the templates directly inside but none of the sub-folders. This helps reduce noise from your repository by avoiding deeply nested, unnecessary items.

The Risk: Forgetting that "grandchildren" are completely ignored.

Deep dive: 'ItemAndDescendants'

ItemAndDescendants is the default and most comprehensive scoping option. It is used to capture the root item as well as it's entire tree structure (children and grandchildren included). You'll want to choose this option when you're looking to serialize, version control and deploy an entire subtree of items. It ensures the structure remains intact across environments. Performance Impact: Can be heavy. On large content trees, this can significantly slow down ser pull and ser push operations.

When to use it:

• Templates: You almost always want the entire template tree.
• Renderings/Layouts: Ensuring the full component definition is captured.

The Risk: The "Content Overwrite" nightmare. If used on a content node, a developer might accidentally revert a content author's work to an old version stored in Git.

The safety valve: using 'Ignored'

Ignored is used to exclude specific items or entire sub-trees from the serialization process. There are a number of instances when Ignored would be useful:

• Environment-specific data: Items that are only relevant within certain environments (e.g. local developer test items)
• Volatile or dynamic content: Content that is frequently changing or generated dynamically (e.g. analytics data, session data)
• Large volumes of content: Authorable page content, for example blogs, that are managed via a content pipeline rather than by developers. Ignoring these improves the performance by avoiding unnecessary serialization checks
• Legacy or obsolete items: If items are no longer actively used but are still being kept, you can avoid them interfering with current deployment and development processes
• Items matched by a broader rule: SCS uses the first-match-wins principle, you can define an ignored rule for a specific sub-path that falls under a general ItemAndDescendants include rule. This will ensure that a specific branch is skipped

Strategic comparison table

Choosing the right tool for the job

Scopes are about precision. Use the information above to consider your content tree and project context. You can always run ser pull --whatif before committing your module changes to preview the impact without modifying any data.