Skip navigation

Decide for one or more projects

7 min read
Download PDF

One of the initial decisions of your implementation will be how to divide content in your project and whether you need to use one or more projects.

In most cases, a single project is sufficient to cover typical content needs. You can use collections to divide content in the project to mimic your business structure. But there can be exceptions when you'll benefit from using more projects. Ask yourself if your content can share most of the settings, or you need completely separate partitions of your content that don't share almost anything.

Table of contents

    Key points

    • Use one project unless you're sure you need more. More projects can create obstacles in reusing content.
    • If you choose to use multiple projects, think about connecting them so that your content creators and administrators don't have unnecessary administration overhead.
    • Agencies should always create separate subscriptions for their clients.

    Questions that will help you

    To decide if you need one or multiple projects, answer the following questions. 

    Are you going to…

    1. Use the same set of workflows for all content?
    2. Use the same set of roles without overlap on all content?
    3. Keep your content model unified across all content?
    4. Need to reuse content across all content?

    If you’ve answered positively to all the questions, go with one project. If you've answered negatively to any of those, consider multiple projects. However, continue reading before you make your final decision.

    Digital agencies implementing for a client

    For different clients, create separate projects and even subscriptions. There is typically nothing shared across clients and you want them to be clearly separated entities.

    If you repeat certain patterns when implementing your clients' projects, create a project template. You can clone the template for every new client and use it as a starting boilerplate to make your life easier.

    What's shared within one project

    What are the main settings that are shared within a project? Here's what you can have only once in each project:

    • Content model and related functionality
    • Workflows
    • Roles
    • API keys and webhooks

    Website management

    Web Spotlight

    One of the main decisions is also whether you're going to use Web Spotlight. Web Spotlight is especially suitable for projects focused on websites. To make website management easier, Web Spotlight displays a page tree, that becomes the centerpiece of work for your web admins and editors.

    Where can I find more about Web Spotlight?

    Have a look at the dedicated Web Spotlight section.

    However, Web Spotlight is primarily intended to work with exactly one page-tree hierarchy. That's not a problem when you run a website and, for example, a mobile app.

    You can also run multiple websites in one Web Spotlight, but this requires you to double down on the authoring experience.


    Running a multi-site project sure comes with its challenges. One of them is providing a smooth authoring experience when it comes to previewing your content before it goes live. 

    With spaces, you can configure multiple previews within one project. This means you can preview each piece of content in the context of the appropriate website to make sure it looks good before publishing. Using spaces for multiple previews also means that you can have Web Spotlight set up separately for each of your websites.

    All in all, if you intend to run multiple websites that don't share any content, model, or taxonomies, it's all right to use separate projects. However, if you plan to share anything among the websites, go for one shared project.

    As you can see, there isn't one universally correct option. You need to evaluate your requirements and decide based on that. Consult our Customer Success Services team if unsure.

    Keep separate content in one project

    Your projects can grow faster than you expect. To scale your content production, use collections to group your content based on your organization's needs and structure.

    Where you'd imagine multiple projects, imagine collections. With the right setup, they create clear boundaries for content and ensure that the right people have access to the right content.

    For instance, you can define a collection for global content that's to be shared and reused, and other collections for content that's specific. 

    That specificity can take a variety of forms. You can use collections for markets, regions, departments in your organization, marketing campaigns, and more.

    Read more about collections in the next article of this series.

    Multiple development environments

    A typical scenario that can change your decision is that you want your developers to implement and test separately from your live application. No one wants to have a website down when the devs are working, right? Yet, you can achieve the best results if developers work with real data. For this scenario, use environments instead of separate projects. supports multiple environments per project. Instead of copying projects, you create a development environment with a snapshot of the current data. Your developers can then safely work in the development environment. When they're done, they'll merge the changes into your live production environment.

    Minimize the drawbacks of more projects

    Even if you've decided for multiple projects, there still might be benefits of a single-project approach that you'd like to use in your setup.

    For example, if you have content managed in one project and the content should be reused in other projects, implement a custom element for connecting projects. This element enables your editors to reuse content from that “global” project in other projects.

    For syncing content among multiple projects, use webhooks and another service suitable for this (such as Azure functions). Or, you might also want to display content from more projects in one place. Both scenarios are possible when you share content between more projects.

    Content model reuse is a bit more tricky, but you can use our Management API to keep the content model in sync among multiple projects.

    What's next?

    Deciding whether to use one or more projects opens the door to creating a content model

    Are you going to manage multi-site content within one project? If so, decide whether to use spaces.