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. Note, if you're not yet using organizations, hubs are at the top level.
- Repositories are where content and slots are stored.
We've introduced organizations as part of our account structure, to provide improved flexibility for granting Dynamic Content user permissions. If you currently use personas to grant user permissions, please contact your Amplience Customer Success Manager or Amplience Support about migrating to roles.
For information about the different types of users and permissions, see Permissions.
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.
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. Our recommendation is to have one organization only, however, multiple organizations may be used.
Introducing organizations to our account structure, provides a way of connecting hubs and repositories. This enables your administrators to manage user access to organizations, and their hubs and repositories. You can control user actions at a granular level, by assigning different roles to users for individual hubs and repositories.
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 a Dynamic Content user belongs 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.
Users become members of an organization in one of the following ways:
Automatically - the first time they use SSO to log in to Dynamic Content for that organization
Manually - by being invited to be members of an organization
Account statusLink copied!
Each organization member has an account status, that determines whether or not they can be assigned roles for accessing content.
| Account status | Description |
|---|---|
| Active | Roles can be assigned for the member |
| Invited | Member has no roles and cannot have roles assigned |
When a user joins an organization automatically, their account status is 'active'. When an invitation is sent to a member, their account status remains as 'invited' until they accept the invitation or log in to Dynamic Content using SSO.
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).
Hub permissionsLink copied!
Using the account management panel, your organization administrator can grant Dynamic Content users permissions by assigning roles. The roles are assigned on a per hub, per repository basis and can be managed yourself, from the account management panel.
If you currently use personas to grant Dynamic Content user permissions, they are granted at the hub level, through requests to Amplience support. All users of a hub can at least view all of the content within the repositories inside that hub.
Roles are replacing personas for granting Dynamic Content user permissions. If you currently use personas to set permissions, please contact your Customer Success Manager or Amplience Support about migrating to our more flexible role-based permissions.
For more information about roles and personas, see Permissions.
Hub characteristicsLink copied!
- Content cannot be shared across hubs.
- However, 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.
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.
When granting 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.
Using roles to grant user permissions, your administrator can assign roles on a per repository basis. See Assigning repository roles
If you are using personas to grant Dynamic Content user permissions, there is less granularity than with roles. Although a user can view content in all repositories within a single hub, their ability to create content may be limited to certain repositories.
ScenariosLink 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.
These scenarios incorporate account management features, such as organizations and roles. If you've not yet migrated to using roles, see the scenarios for Accounts not using organizations.
Sharing content between brandsLink 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.
Accounts without organizationsLink copied!
The following scenarios explain the use cases for single versus multiple hubs, where you have not yet migrated to using organizations and roles. The scenarios are similar to those shown above, with the following exceptions:
- your environment will have hubs as the top space, rather than organizations
- permissions for your Dynamic Content users are controlled using personas, rather than roles
For each use case we'll show the way that hubs and repositories are organized and how this affects the users who are assigned the personas of planners, content producers and developers.
Sharing content between brandsLink 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 user persona can doLink copied!
Content producers: can view content for both brands x and y and create content in both repositories if they are given permission to do so
Planners: 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 user persona can doLink copied!
Content producers: cannot share content between brands, but can be sure that content is kept separate.
Planners: 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.
