Skip to Main Content
Customer Feedback

We love feedback from you on our products and the problems in your daily work that you would like us to solve. Please describe the challenge you're encountering and your desired outcome. Be as detailed as possible.

For technical issues or bugs please head to Support or our Developer Community. You can assign up to 10 votes in total. Thank you for your feedback.

Status explanation: 'Future Consideration' = Continuing to collect further feedback, not planned at this time. 'Investigating' = Prioritized for deeper customer and feasibility investigations ahead of planning development.

Categories Technical
Created by Guest
Created on Jan 29, 2022

Improve IContent API:s to support bulk actions


CMS heavily relies on CRUD operations for IContent. And therefore there are Content Events for single item operations.

And then subscribing tasks such as Search&Navigation Indexing and other event subscribers also reacts on every individual Content Event.

Long running scheduled jobs (that runs many hours) that Creates/Updates/Deletes/Moves IContent is bombarding the DB for every single action.


One missing feature in CMS is the support of bulk actions for IContent.

Take the example of the long running scheduled jobs (that runs many hours) that Creates/Updates/Deletes/Moves IContent and is bombarding the DB. Another approach could be more like the Entity Framework, just making state changes and when all changes are done (in that context), just commit the changes to the DB in one large bulk request (at least in an API point of view, what is optimized under the hood is the product owners responsibility).

If adding such feature/API:s to update an bulk of IContent, then there could be bulk Content Events, and then content event subscribing features could react when all bulked actions is being completed.

What to gain in the short terms

An API that supports bulk actions would immediately show intents of bulk usage. Custom event subscribing could listen and act on native implemented bulk events instead of work around logic.

What to gain in the long terms

It would put bulk actions on the CMS roadmap, while still being useful in the event subscribing aspect, it would be possible to safely, over time, optimize underlying internal implementations and integrations, like lower the number of individual operations to various integrations. Given the database design there wouldn't possibly be a great performance gain in doing bulk operations in current state, but it would point out a direction where you in the future could find a path where you could do optimization to lower the number of DB-requests and make bulk updates in DB-calls too, removing an infrastructure bottleneck, improving stability over time.