Account structure
When you are deciding how to set up Dynamic Content for your company, a key consideration is how to organize your Amplience account environment. We provide an account structure for Dynamic Content consisting of organizations, hubs and repositories.
- Organizations are top level containers within which hubs and repositories exist.
- Hubs are spaces in which content is organized and scheduled, and these hubs contain repositories.
- Repositories are where content and slots are stored.
OrganizationsLink copied!
In simple terms, an organization is a top level entity, or container, within which hubs and repositories are organized. They provide you with a flexible, multi-environment setup within which users can access as many environments as they need. You can retain distinct hubs and repositories for your different brands, sites and regions, that your users can access using a single login account.
Organizations are created for you by Amplience.
Depending on your requirements and how you share content between brands, typically you will need just one organization, however multiple organizations are permitted. In addition, within each organization you may choose to have multiple hubs, or use one hub and multiple repositories to contain the content for each brand.
Organization characteristicsLink copied!
- Permissions for different types of users are set using roles
- Users must belong to an organization to access its content
- Each organization member is assigned a role of either admin or member
- Where multiple organizations are used, users can belong to more than one organization
- Content cannot be shared across organizations
Organization membersLink copied!
When Dynamic Content users belong to an organization they can access its child hubs and repositories using a single login account. We refer to users who belong to an organization as members.
HubsLink copied!
Hubs are organized around a set of design principles that you can use to help decide whether to have one or multiple hubs.
The image below shows an account with multiple hubs (1) and the "Amplience Product Hub" selected. This hub contains several repositories (2 in the image below).
Hubs are created for you by Amplience.
Hub characteristicsLink copied!
- Content cannot be shared across hubs.
- Content can be shared and linked to across repositories within the same hub. So you can create a content item in one repository and include content stored in another.
- Events and editions are scheduled within a single hub. So if you want an overall view of the scheduling calendar across many brands, then you may wish to consider a single hub. However, in some cases you may want to keep the calendars separate.
- Many settings, such as the publishing endpoint (the subdomain to which your content is published) are set at a hub level. Multiple hubs may publish content to the same endpoint.
- Hubs may have access to Content Hub asset stores. Typically, they have read and publish permissions to assets in one or more asset stores so that when the content from a Dynamic Content hub is published, the linked assets are also published.
Hub permissionsLink copied!
Your organization administrator can set permissions for Dynamic Content users by assigning hub roles.
For more information about permissions and roles, see Permissions.
RepositoriesLink copied!
Content and slot types are registered with hubs and enabled on repositories. So you can choose which types of content can be created in each repository, or just choose to limit the number of content types that are available. See Enabling a content type on a repository.
Organization administrators can create and manage repositories.
Repository permissionsLink copied!
When setting user permissions for repositories, typically you will want users who are creating content to be able to do so in one or more repositories, but the users who publish, to only be able to view the content.
Your administrator can set permissions by assigning roles on a per repository basis. See Assigning repository roles
Deciding your account structureLink copied!
Here are scenarios that help to explain the use cases for single versus multiple hubs. For each use case we'll show the way that hubs and repositories are organized and how this affects the role of authors, publishers and developers.
Single hub with multiple repositoriesLink copied!
If you have multiple brands and want to share the content across brands and possibly across channels and locales, you may choose to have one hub and several repositories.
The image below shows a possible set up of repositories all in a single hub.
What each type of user can doLink copied!
Authors: can view content for both brands x and y and create content in both repositories if they are given permission to do so
Publishers: can view the entire content scheduling calendar and schedule editions across both brands
Developers: can be given permission to create slots in both slot repositories.
If the layout of the sites or apps for both brands is very similar, then you might choose to use the same slots for each brand and store the slots in a single repository.
Multiple hubsLink copied!
If you have multiple brands and do not wish share content between them, or simply wish to keep the content entirely separate, then the multiple hub approach is one to consider.
A very simple example of this is shown below.
What each type of user can doLink copied!
Authors: cannot share content between brands, but can be sure that content is kept separate.
Publishers: can view the scheduling calendar for one brand at a time and must switch hubs to view the other brand schedule.
Developers: can be given permission to each hub to deploy content types and slots, but must set them up on each hub.