Welcome to SUGNL

Jan Bluemink · Aug 15, 2026

Sitecore Content and Layout Migration Part 3: Sitecore PowerShell Extensions

Ronald van der Plas · Aug 10, 2026

New in Content Hub Power Extension: Cheat Sheets

I’ve released a new version of the Content Hub Power Extension, now including a new Cheat Sheets section. The first cheat sheets focus on Scripting, Triggers and Actions, giving you a quick reference while working with Sitecore Content Hub. Instead of searching through documentation or old examples, you can keep the most useful information close at hand while building and configuring your solution. This is only the start. I plan to expand the cheat sheets with more useful Content Hub topics over time. If you’re already using the Content Hub Power Extension, make sure to update to the latest version and give it a try!

Ronald van der Plas · Jul 30, 2026

Content Insights Tip #83 | Bulk vs Non-Bulk in Sitecore Content Hub: Choosing the right execution strategy

When creating an External Mass Action in Sitecore Content Hub, one of the configuration options you'll encounter is the Bulk toggle. It's easy to overlook. After all, it is just a single checkbox in the Selection component, surrounded by several other settings that appear equally important. Yet this checkbox has an impact that most people might not realise. It doesn't simply determine whether multiple assets can be processed together. Instead, it changes how Content Hub communicates with your external service and, more importantly, where the responsibility for processing those assets lives. At first glance, the difference seems straightforward. With Bulk disabled, Content Hub sends a single request for every selected asset. Enable Bulk, and those assets are grouped into a single request. While that's technically correct, it doesn't explain why Sitecore offers both options or when one approach is more suitable than the other. To answer that question, let's first look at what actually changes. Non-Bulk processing When Bulk is disabled, every selected asset results in its own HTTP request. If a user selects three assets, your endpoint is invoked three times. Each request contains information about a single asset, making every execution completely independent from the others. Request 1 { "TargetId": 34181, "TargetIdentifier": "xEYMBs3UTo6ZDN_Xp8ykgg", "context": {} } Request 2 { "TargetId": 34253, "TargetIdentifier": "o-SNrVDwTRWIzcHG0cu8VA", "context": {} } Request 3 { "TargetId": 34127, "TargetIdentifier": "hqFQTkdmQGeHDIJDzBnHRw", "context": {} } This execution model has an important consequence. Content Hub is invoking your service once for each selected asset. Your service doesn't know how many assets the user selected, because each request always contains a single asset. Bulk processing With Bulk enabled, the interaction changes. Rather than invoking your endpoint once per asset, Content Hub does a single request that contains all selected assets. { "targets": [ { "TargetId": 34181, "TargetIdentifier": "xEYMBs3UTo6ZDN_Xp8ykgg", "context": {} }, { "TargetId": 34253, "TargetIdentifier": "o-SNrVDwTRWIzcHG0cu8VA", "context": {} }, { "TargetId": 34127, "TargetIdentifier": "hqFQTkdmQGeHDIJDzBnHRw", "context": {} } ] } Notice that not only the number of HTTP requests changes, also the JSON contract itself changes. Instead of receiving a single asset, your service receives a collection of assets and becomes responsible for processing them. That distinction may appear subtle, but architecturally it is significant. An execution strategy, not a performance setting One misconception I regularly encounter is that Bulk should simply be enabled for better performance. While it often reduces the number of HTTP requests, that's not the reason why the option exists. The real question is much simpler: Where should the iteration happen? Should Content Hub invoke your service once for every asset, or should your service receive a collection of assets and decide how to process them? That decision has consequences far beyond the transport layer. It affects how you design your queues, how you prioritise work, how you handle failures, and ultimately how your application scales. Consider an AI enrichment service that supports both scheduled processing and urgent requests. Every night, editors submit hundreds of assets for transcription or metadata generation. Those requests are ideal candidates for Bulk processing because the service can optimise throughput and process the work whenever capacity becomes available. Now imagine an editor who needs a single asset enriched immediately before publishing. That request shouldn't wait behind hundreds of scheduled jobs. Instead, it can use a separate Non-Bulk action that places the work directly into a priority lane. Although both actions call the same service, they represent two completely different execution strategies. This is why the choice between Bulk and Non-Bulk should always be driven by functional requirements rather than performance alone. When Content Hub is the caller There's another architectural principle worth mentioning. It can be tempting to assume that because Content Hub initiates the request, the data it sends is always ready to process. In practice, your service should never rely on that assumption. Your endpoint should validate whether an asset is still available, whether it is in the correct lifecycle state, and whether processing it actually makes sense. Likewise, if processing the same asset twice would cause problems, your implementation should be resilient enough to handle duplicate requests gracefully. These responsibilities belong to the service, not to Content Hub. The platform is responsible for invoking your endpoint. Your responsibility is to build an endpoint that behaves correctly under all circumstances. Conclusion The Bulk toggle may be one of the smallest configuration options in Sitecore Content Hub, but it represents an important architectural decision. It determines who is responsible for iterating over assets, influences how your application handles prioritisation and scalability, and shapes the overall execution model of your integration. The next time you create an External Mass Action, don't ask yourself whether Bulk is faster. Instead, ask a different question: Where should the iteration happen? More often than not, the answer to that question will also tell you which option to choose.