David Klement, Tomas Nosek, Jan Cerman, Boris Pocatko
3 minutes
Spaces / Collections / Projects
One of the initial decisions of your Kontent.ai implementation is how to divide content in your project and whether you need to use more than one project.
Go with a single project as a rule of thumb
A single project is usually sufficient to cover typical content needs. You can use collections to divide content in the project to mimic your business structure. The rule of thumb here is to use one project unless you’re sure you need more. It’s hard to reuse content across projects.As with anything, there are exceptions. If you have entirely different partitions of content that share little to nothing, multiple projects may be the way to go.
Questions that will help you decide
When figuring out if you need one or more projects, it all comes down to the question of content model and content reuse:
Do you need to reuse content across all your content?
Can you have one unified content model?
If you answered positively to either of the questions, go with one project. It’s the safest option. Sharing content among multiple projects is complicated, and you can almost always accommodate your content model to fit all your content into one project.If you’ve answered no to both questions, you most likely have multiple completely separate content repositories that can safely be distributed each into its own project.
What’s shared within one project?
Here are the main settings that are shared within a project:
Content model and related functionality
Workflows
Roles
API keys and webhooks
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.Another option for content division is to use spaces. Spaces are primarily focused on deploying multiple websites from within one project. With spaces, you can configure multiple Web Spotlight roots and multiple corresponding previews within one project.All in all, where you’d imagine multiple projects, imagine collections or spaces (or both). With the right setup, they create clear boundaries for content and ensure that the right people have access to the right content.If you intend to run multiple websites or apps 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.
What's next?
What about channels?
When you intend to publish for multiple channels, using a separate project for each channel may be tempting. However, channels share most of the content, and the content model, so using multiple projects would make your content operations cumbersome, manual, and error-prone. In this section, you’ll learn about your options to set up projects for smooth multichannel publishing.
Digital agencies implementing for a clientFor 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.
