PageBuilder permissions by website
PageBuilder Editor 3.23 includes a long-awaited update for PageBuilder permissions: the View, Write and Publish privileges in PageBuilder now respect website settings. This update helps multisite customers better manage the scope of editorial permissions in PageBuilder.
Previously, if a user had View, Write or Publish privileges for any website, they were able to view, write or publish changes to any page, regardless of what websites that page was assigned to.
Now, users can write and publish pages assigned to only websites they have permissions for, as configured in the Permissions application.
This change only affects multisite customers using PageBuilder Editor.
What’s changing in this release?
We are updating PageBuilder Editor to respect website permissions, to match existing permissions behavior established in Composer and Photo Center galleries. See the table below for a detailed explanation of what is changing:
Permission use case | PageBuilder Editor 3.22 and earlier | PageBuilder Editor 3.23 and later | Existing Composer behavior |
|---|---|---|---|
1. User has View permission for a subset of an organization’s websites | Within PageBuilder Editor, a user can View any page, regardless of what website(s) the page is assigned to | Within PageBuilder Editor, a user can View only pages assigned to the websites they have permissions for. Additionally, users will only see websites they have permission for in the landing page filter. *See note about Composer unpublished article preview behavior | User can View only stories assigned to the websites they have permissions for. Additionally, users only see websites they have permission for in the landing page filter |
2. User has Write permission for a subset of an organization’s websites | User can Write changes to any page, regardless of what website(s) the page is assigned to | User can only Write changes to pages if they have Write permissions for all websites the page is assigned to. If the page is assigned to some websites the user has permissions for, and some that they do not have permissions for, then the user can only View that page. | User can only Write changes to stories if they have Write permissions for all websites the story is assigned to. If the story is assigned to some websites the user has permissions for, and some that they do not have permissions for, then the user can only View that story. |
3. User has Publish permission for a subset of an organization’s websites | User can Publish changes to any page, regardless of what website(s) the page is assigned to | User can only Publish changes to pages if they have Publish permissions for all websites the page is assigned to. If the page is assigned to some websites the user has permissions for, and some that they do not have permissions for, then the user can only View that page. | User can only Publish changes to stories if they have Publish permissions for all websites the story is assigned to. If the story is assigned to some websites the user has permissions for, and some that they do not have permissions for, then the user can only View that story. |
4. User has View, Write, and/or Publish permissions for All Sites | User can View, Write, and/or Publish all pages | Same behavior as 3.22 - nothing changes. | User can View, Write and/or Publish all stories. |
Who does this change affect?
This change only affects Arc customers that have more than 1 website in Site Service - i.e., multisite customers - who use PageBuilder Editor. Single-site customers are not affected by this change, because their users can only have access to 1 website. (They effectively fall under use case #4 in the table above). Headless customers (who do not use PageBuilder Editor at all) are not affected by this change either.
Does my organization need to make any changes ahead of this release?
Multisite customers who use PageBuilder Editor should review their Permissions setup to evaluate if they need to make any changes as a result of this release. Your TAM will contact your organization individually with a list of any Squads that may be affected by this change, so you can review them ahead of the release.
We anticipate that most Squads will not require any changes - this release simply enforces website permissions that your organization configured intentionally in the past.
However, because PageBuilder Editor hasn’t enforced website permissions before, it’s possible that some users who regularly need to access Pages across multiple websites don’t actually have the appropriate website permissions to do that. Here’s an example scenario:
A user (“Jane Smith”) was originally hired to be a homepage editor for The Gazette website. She was assigned to a Squad that technically only has Publish permissions in PageBuilder for The Gazette.
Jane has since been promoted, and is now a homepage editor for multiple websites (The Gazette, The Intelligencer, and The Globe). Up until now, she has been able to publish the homepage for all of these websites, since PageBuilder permissions by website were not enforced.
When PageBuilder 3.23 is released to Production, permissions by websites are enforced. Jane now only has the ability to publish The Gazette.
To remedy the situation, an administrator adds Jane to an additional Squad that has PageBuilder publish permissions in all three websites (The Gazette, The Intelligencer, and The Globe).
We recommend reviewing the list of affected Squads with your internal stakeholders to determine if any changes need to be made.
I have users who will need access to View/Write/Publish pages assigned to websites in PageBuilder beyond what they’re allowed to today. What are my options for making this change?
If you discover that you have users who fit this scenario (they need to be able to view, write or publish pages for additional websites beyond what they are assigned permissions for today), there are a few different ways you can make this change:
Option | Steps to complete | Notes |
|---|---|---|
Add individual users to an additional Squad that gives them the needed website permissions. | Add the individual users to an appropriate Group using the identity platform your organization uses for this purpose | This is the best option if you have only a few individual users who need additional access (rather than an entire existing Group) |
Adjust an existing Squad to grant access to the needed websites | Change the websites assigned to the squad to include all websites that the Group needs access to | Depending on how your Squads are configured, this may also unintentionally grant users access to edit and publish stories in Composer. If this is the case, creating a new squad may be the safer option. |
Create a new Squad to grant users access to the needed websites | Create a new Role and a new Squad that grants only the specific privileges that the Group needs access to | This may be a safer option to grant users only access to the sites they need |
Does this release change any permissions behavior for Templates or Resolvers?
No. Access to resolvers is already handled by a separate privilege (Create and Edit Resolvers) and that is not changing. Templates are not assigned to a website, so users with View, Write and Publish permissions will continue to be see all Templates, regardless of what websites they have permissions for.
Does this release change any permissions for previewing unpublished stories from Composer?
No, nothing is changing regarding the ability for Composer users to preview unpublished stories. This change only affects users when they are in the PageBuilder application itself.
I’ve kept many editorial users out of PageBuilder because permissions were too broad. How can I take advantage of this change?
If you’re a multisite customer who up until now has kept many of your editorial staff out of PageBuilder Editor because of the lack of website permissions, you can now introduce new Squads that take advantage of these capabilities.