Skip navigation

Decide for one or more projects

6 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 more than one project. The main difference is between using one and using more projects. Both approaches have benefits in different use cases. If you choose well, you can maximize the benefits while not being affected by any downsides.

In most cases, a single project is sufficient to cover typical content needs. You can divide content in the project to mimic your business structure. Though there might be exceptions when you'll benefit from using more projects. Ask yourself if your content can share most of the settings or if you need to separate your content in some way.

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.

    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

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

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

    Using 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, which will become the centerpiece of work for your web admins and editors.

    Where can I find more about Web Spotlight?

    Web Spotlight is described in detail in this section.

    However, Web Spotlight is primarily intended to work with exactly one page-tree hierarchy only. It isn't a problem when you'll run a website and, for example, a mobile app.

    If you intend to run multiple websites in, the default choice is to use a separate project for each website. Though, if you'd like to share the content model or content itself among websites, there is an option to run more websites in one Web Spotlight.

    As there isn't one universally correct option and the right option will vary based on your requirements, decide based on your evaluation. Consult with our Professional Services team if unsure.

    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. Yet, you can achieve the best results if developers work with real data. For this scenario, you don't need to create multiple projects. allows each project to create more environments for such purposes. Instead of copying projects for your developers, you create an environment with a snapshot of the current data. Your developers can then improve your project and applications feeling safe. When the devs are finished with the improvements, they'll merge them into the live app.

    Keep separate content in one project

    Your projects can grow big sooner than you expect. To scale your content production, prepare collections to group your content how you see fit. Even with lots of content, you'll find what you need.

    For instance, collections help you define which content is global (and to be shared and reused) and which content is specific. That specificity can take a variety of forms. You can have a collection for content specific to a market, region, department in your company (or any other business unit), marketing campaign, and more.

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

    Maximize the benefits of more projects

    Even if you've decided on more projects, there still might be some benefits of one project 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. This element will allow your editors to reuse content from that “global” project in any number of 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. The next step is choosing how to divide your content with collections.

    Activate collections for your project