This Bloomreach Experience Manager feature requires a standard or premium license. Please contact Bloomreach for more information.

Projects allow you to manage a group of changes to your channels and content that require a workflow process before publication.

We recommend the use of the Projects feature for (sets of) channels with up to 200 pages and up to 200 documents at the same time. Larger numbers may negatively affect brXM UI responsiveness.




A project holds a set of related channel and content changes.

The changes contained within a project, once reviewed and ready, can be merged to ‘core’ or run as a campaign.

When you add a channel to a project you are effectively saying that you want to make a set of changes to that channel, which can then be run as a campaign or merged to core (‘made live’) when ready.

When you add a document to a project you are doing the same thing; you are choosing to edit a document and have the edited content ‘go live’ (be published) when the project is run as a campaign or merged.

A channel, when initially added to a project, is duplicate to the channel as it is live on core. For example, if you add the ‘UK’ channel to a project, that channel, in the context of a project, will look the same as the ‘UK’ channel on core. If the UK channel is changed on core after being added to a project, and you want the project’s UK channel to reflect these changes on core, you can update the project.


A campaign is a project that is 'live' without being merged to core. Starting a campaign publishes all channel and content changes in the project. A running campaign can either be stopped (reverting the channels and content back to core) or merged to core (making the changes permanent). Campaigns can either be started and stopped manually or they can be scheduled to start and stop at certain dates and times.


The core is the main state of all channels and documents. Changes made in any project do not affect the core until a project is merged into the core. Changes to the core do not affect any project until a project is updated.


During a review, each channel and content change in a project is verified by at least two webmasters and is either accepted or rejected.


Any webmaster can accept a project’s channel and content changes when the project is in review. Each channel or document change within a project must be accepted by two webmasters before the project can be merged into the core or run as a campaign.


Any webmaster can reject a channel or content change within a project when the project is in review.

A rejection of any change contained within a project will prevent the project from reaching an ‘approved’ state, which means that it cannot be merged or run as a campaign.

When a document or channel is rejected it becomes editable again, and it is possible to restart the review of the document or channel. Alternatively, you can choose to remove the document or channel from the project entirely (rather than editing it and restarting the review).


Merging is the process of applying channel changes in a project to the core; it puts the changes live. It also publishes all documents contained within a project. During the merge process, the channel changes contained in a project will overwrite what is on core. For example, a component within a project is changed to show banner Y, on core the same component shows banner X- once the project is merged to core the component on core no longer shows banner X but instead shows banner Y.


Updating a project is applying channel changes made to core since the project was started or last updated, to channels contained in the project. For example: if a component on the UK channel was changed on core, you can ensure this component change is represented within the UK channel added to a project, by ‘updating’ the project.

Please note that updating a project includes only channel changes on core; content changes on core are not included in an update.


As a project can contain both channel and content changes, from multiple content editors, authors, marketeers etc., it is useful for changes made to be logged in some way - so that it is transparent to all what a project contains and what the impact on core will be when that project is merged. This is why it is possible to add comments within a project; to log and keep track of changes made.

The ability to comment within a project is also useful when a change within a project is rejected; the user who rejected the change can explain why they did so and immediate action can be taken.

Did you find this page helpful?
How could this documentation serve you better?
On this page
    Did you find this page helpful?
    How could this documentation serve you better?