“Content Governance” in KIBO CMS is really two mechanisms working together: “Content Reviews”, the per-page “Request Review” workflow we’ve referenced in prior videos, and “Workflows”, the configurable set of steps Content moves through, between “Draft” and “Published”. Neither of those actually functions without the right setup underneath: “Roles”, defined in both the KIBO Admin UI and the KIBO CMS Admin, determine who can create content, who’s required to review it, and who’s allowed to publish it.In this video, we’ll build that setup end to end — reviewing a Role and Team in CMS Admin, adding a custom step to a Page Workflow, and then switching between two Roles to see the full review cycle play out: a content edit, a rejection, a revision, and a final approval and publish. “Content Governance” in KIBO CMS is really two mechanisms working together: “Content Reviews”, the per-page “Request Review” workflow we’ve referenced in prior videos, and “Workflows”, the configurable set of steps Content moves through, between “Draft” and “Published”. Neither of those actually functions without the right setup underneath: “Roles”, defined in both the KIBO Admin UI and the KIBO CMS Admin, determine who can create content, who’s required to review it, and who’s allowed to publish it. In this video, we’ll build that setup end to end — reviewing a Role and Team in CMS Admin, adding a custom step to a Page Workflow, and then switching between two Roles to see the full review cycle play out: a content edit, a rejection, a revision, and a final approval and publish. First, let’s quickly review User Roles and Permissions in the KIBO Admin UI. To do that, in the left nav menu, on the “SYSTEM” tab, we’ll click “Permissions”, then click “Roles”. First, let’s quickly review User Roles and Permissions in the KIBO Admin UI. To do that, in the left nav menu, on the “SYSTEM” tab, we’ll click “Permissions”, then click “Roles”. This opens the Roles menu, showing all roles available on this platform. This opens the Roles menu, showing all roles available on this platform. There are already two KIBO “System Roles” that could likely be used for KIBO CMS - “Content Manager” and “Site Designer”.Important Note: for KIBO Roles to function in KIBO CMS, a Role with the exact name has to exist on the CMS Admin side as well — the two systems are tied together by the matching Role names. We could just as easily create a role called “Abracadabra” in both places, and as long as the name matches exactly, CMS Admin would treat it as that role’s counterpart, with its own independently defined permissions. There are already two KIBO “System Roles” that could likely be used for KIBO CMS - “Content Manager” and “Site Designer”. Important Note: for KIBO Roles to function in KIBO CMS, a Role with the exact name has to exist on the CMS Admin side as well — the two systems are tied together by the matching Role names. We could just as easily create a role called “Abracadabra” in both places, and as long as the name matches exactly, CMS Admin would treat it as that role’s counterpart, with its own independently defined permissions. Opening “Site Designer” shows the KIBO Admin’s permission model — a list of individually named “behaviors,” organized under a “Behavior Category”.Important Note: these behaviors have nothing to do with what’s allowed or restricted inside KIBO CMS itself — that’s defined separately, in CMS Admin’s own Roles menu, which we’ll get to shortly. What these behaviors actually control is more basic: whether this Admin UI Role can reach the “Page Builder” menu item at all. That access comes from the “Site” behavior category specifically. Opening “Site Designer” shows the KIBO Admin’s permission model — a list of individually named “behaviors,” organized under a “Behavior Category”. Important Note: these behaviors have nothing to do with what’s allowed or restricted inside KIBO CMS itself — that’s defined separately, in CMS Admin’s own Roles menu, which we’ll get to shortly. What these behaviors actually control is more basic: whether this Admin UI Role can reach the “Page Builder” menu item at all. That access comes from the “Site” behavior category specifically. Next, we’ll quickly review Users. Back on the “SYSTEM” tab, we’ll click “Permissions” again, then click “Users”. Next, we’ll quickly review Users. Back on the “SYSTEM” tab, we’ll click “Permissions” again, then click “Users”. This is where a Role is applied to a user — we can click the “Add User” button on the top right, and in the resulting modal window supply the user’s email and select the applicable Role. We could also change the Role of an existing user here.In this example, we already have a user with one of the two Roles we highlighted earlier. We will be using this “Site Designer” Role throughout this video to demonstrate Content Governance in KIBO CMS. This is where a Role is applied to a user — we can click the “Add User” button on the top right, and in the resulting modal window supply the user’s email and select the applicable Role. We could also change the Role of an existing user here. In this example, we already have a user with one of the two Roles we highlighted earlier. We will be using this “Site Designer” Role throughout this video to demonstrate Content Governance in KIBO CMS. Now that we’ve reviewed the Roles and Users in the KIBO Admin Ai, and how they are tied to KIBO CMS, we’ll navigate to the CMS Admin page.Back in the left nav, on the “MAIN” tab, we’ll click “Content”, then click “Page Builder”. Now that we’ve reviewed the Roles and Users in the KIBO Admin Ai, and how they are tied to KIBO CMS, we’ll navigate to the CMS Admin page. Back in the left nav, on the “MAIN” tab, we’ll click “Content”, then click “Page Builder”. This will open the KIBO CMS Admin page.We discussed this page in-depth in a previous video. This will open the KIBO CMS Admin page. We discussed this page in-depth in a previous video. Next, we’ll discuss “Roles” and “Teams” in the KIBO CMS Admin, and how they are configured and managed.In the left nav menu, under “Settings”, we’ll click “Roles”. Next, we’ll discuss “Roles” and “Teams” in the KIBO CMS Admin, and how they are configured and managed. In the left nav menu, under “Settings”, we’ll click “Roles”. This is the CMS Admin’s own Roles list — a separate, smaller list from what we saw earlier in the KIBO Admin UI. Right now it holds four Roles: “Content Manager”, “Admin”, “Site Designer”, and “Full Access”.Important Note: “Content Manager”, “Admin”, and “Full Access” are system-defined roles that come locked from the platform itself and can’t be edited or deleted — their permissions are fixed. “Site Designer” is a custom role, built and fully configurable by us. This is also the case for “Teams”, which we’ll discuss shortly. This is the CMS Admin’s own Roles list — a separate, smaller list from what we saw earlier in the KIBO Admin UI. Right now it holds four Roles: “Content Manager”, “Admin”, “Site Designer”, and “Full Access”. Important Note: “Content Manager”, “Admin”, and “Full Access” are system-defined roles that come locked from the platform itself and can’t be edited or deleted — their permissions are fixed. “Site Designer” is a custom role, built and fully configurable by us. This is also the case for “Teams”, which we’ll discuss shortly. To create a new role, we can click either “New Role” buttons displayed here. To create a new role, we can click either “New Role” buttons displayed here. Rather than build a new Role from scratch, we’ll discuss the existing “Site Designer” Role instead, as it shows every field that is available for a New Role.When building a New Role, we’ll enter the Role “Name”, “Slug”, and optional “Description”. The Slug is auto-generated based on the Name, but can be edited if necessary. In this example, it is greyed out because this Role has already been saved; on a brand-new Role, “Slug” stays editable until the first save.Important Note: to reiterate, whatever “Name” we give a new Role has to exactly match a Role of the same type in the KIBO Admin UI — that’s the dependency tying the two systems’ Roles together. Rather than build a new Role from scratch, we’ll discuss the existing “Site Designer” Role instead, as it shows every field that is available for a New Role. When building a New Role, we’ll enter the Role “Name”, “Slug”, and optional “Description”. The Slug is auto-generated based on the Name, but can be edited if necessary. In this example, it is greyed out because this Role has already been saved; on a brand-new Role, “Slug” stays editable until the first save. Important Note: to reiterate, whatever “Name” we give a new Role has to exactly match a Role of the same type in the KIBO Admin UI — that’s the dependency tying the two systems’ Roles together. Below that is where we configure the Roles’ “Permissions”. Every Permission is organized by feature area, each expandable into its own set of controls. We’ll discuss a few of them to demonstrate the Permissions configuration.Note - the “Copy” button to the right of the “Permissions” title allows users to copy the configured Permissions in a JSON file format for use elsewhere, if needed. Below that is where we configure the Roles’ “Permissions”. Every Permission is organized by feature area, each expandable into its own set of controls. We’ll discuss a few of them to demonstrate the Permissions configuration. Note - the “Copy” button to the right of the “Permissions” title allows users to copy the configured Permissions in a JSON file format for use elsewhere, if needed. Each Permission starts with an “Access Level” — for example, “Audit Logs” is set to “No access” for the “Site Designer” role, since reviewing audit history isn’t part of this role’s job. Each Permission starts with an “Access Level” — for example, “Audit Logs” is set to “No access” for the “Site Designer” role, since reviewing audit history isn’t part of this role’s job. “File Manager” is set to “Custom access” instead, which unlocks its own “Access Scope” and “Primary Actions” controls. It also has a separate “Settings” access scope beneath it, since “File Manager” has two entries in the left nav - one is standalone and manages images, and the other is under the “Settings” menu. “File Manager” is set to “Custom access” instead, which unlocks its own “Access Scope” and “Primary Actions” controls. It also has a separate “Settings” access scope beneath it, since “File Manager” has two entries in the left nav - one is standalone and manages images, and the other is under the “Settings” menu. “Access Level” offers three choices: “No access”, “Full access”, or “Custom access”.Important Note: “Custom access” is what unlocks the finer-grained “Access Scope” and “Primary Actions” controls — the other two options apply blanket access with no further configuration needed. “Access Level” offers three choices: “No access”, “Full access”, or “Custom access”. Important Note: “Custom access” is what unlocks the finer-grained “Access Scope” and “Primary Actions” controls — the other two options apply blanket access with no further configuration needed. “Access Scope” narrows things further — here, the options are “No access”, “Full access”, or “Only entries created by the user”, letting a role see everything, nothing, or just its own work. “Access Scope” narrows things further — here, the options are “No access”, “Full access”, or “Only entries created by the user”, letting a role see everything, nothing, or just its own work. “Primary Actions” sets what can be done within that scope — “Read”, “Read, write”, or “Read, write, delete” — building up from view-only to full control. “Primary Actions” sets what can be done within that scope — “Read”, “Read, write”, or “Read, write, delete” — building up from view-only to full control. The “Headless CMS” Permission follows the same pattern with a few of its own additions — “Read”, “Manage”, and “Preview” checkboxes for “GraphQL API types”, plus separate “Content Model Groups” and “Content Models” sections, each with its own scope and actions. The “Headless CMS” Permission follows the same pattern with a few of its own additions — “Read”, “Manage”, and “Preview” checkboxes for “GraphQL API types”, plus separate “Content Model Groups” and “Content Models” sections, each with its own scope and actions. “Website Builder” is the Permission that matters most for this video. The Site Designer role’s “Pages” access is set to “Full access” scope with “Read, write, delete” Primary Actions.However, the “Publishing actions” — both “Publish” and “Unpublish” — are both left unchecked. This is what enforces the “must request review for all updates” control. “Website Builder” is the Permission that matters most for this video. The Site Designer role’s “Pages” access is set to “Full access” scope with “Read, write, delete” Primary Actions. However, the “Publishing actions” 6 both “Publish” and “Unpublish” 6 are both left unchecked. This is what enforces the “must request review for all updates” control. When we’ve configured all necessary fields and Permissions for the role, we’ll click “Save”. We can come back and edit these Permissions at any time. When we’ve configured all necessary fields and Permissions for the role, we’ll click “Save”. We can come back and edit these Permissions at any time. Next, we’ll look at “Teams”.Back in the left nav, under “Settings”, we’ll click “Teams”. Next, we’ll look at “Teams”. Back in the left nav, under “Settings”, we’ll click “Teams”. This is the CMS Admin “Teams” menu. Here, the Team names happen to mirror the same four names as Roles — “Content Manager”, “Admin”, “Full Access”, and “Site Designer” — but Teams and Roles aren’t the same thing, and aren’t required to be named similarly.Important Note: a “Role” defines a set of permissions; whereas a “Team” is what actually gets assigned to a person or a Workflow step, built out of one or more “Roles”. This is the CMS Admin “Teams” menu. Here, the Team names happen to mirror the same four names as Roles — “Content Manager”, “Admin”, “Full Access”, and “Site Designer” — but Teams and Roles aren’t the same thing, and aren’t required to be named similarly. Important Note: a “Role” defines a set of permissions; whereas a “Team” is what actually gets assigned to a person or a Workflow step, built out of one or more “Roles”. Similar to Roles, we’ll click either “New Team” button to create a new “Team”. Similar to Roles, we’ll click either “New Team” button to create a new “Team”. Just like the Role, we’ll walk through the existing “Site Designer” Team instead of starting blank, but the fields are identical for each — the same “Name”, “Slug”, and optional “Description” fields. Just like the Role, we’ll walk through the existing “Site Designer” Team instead of starting blank, but the fields are identical for each — the same “Name”, “Slug”, and optional “Description” fields. The key field is “Roles” — a “Team” is built by selecting one or more Roles from this list. “Site Designer” the Team is built from “Site Designer” the Role, though a Team could just as easily combine several Roles together. The key field is “Roles” — a “Team” is built by selecting one or more Roles from this list. “Site Designer” the Team is built from “Site Designer” the Role, though a Team could just as easily combine several Roles together. When we’ve completed configuring the Team, we’ll click “Save”. Again, we can come back and edit this Team at any time. When we’ve completed configuring the Team, we’ll click “Save”. Again, we can come back and edit this Team at any time. Next, we’ll discuss “Workflows”. This is where we’ll define exactly when the Content Review needs to happen when creating or editing Website Builder Pages.Back in the left nav menu, under “Website Builder”, we’ll click “Workflows”.Important Note: a separate “Workflows” menu also lives under “Content Modeling” — it’s the same mechanism, but scoped to Content Model entries instead of Pages. Next, we’ll discuss “Workflows”. This is where we’ll define exactly when the Content Review needs to happen when creating or editing Website Builder Pages. Back in the left nav menu, under “Website Builder”, we’ll click “Workflows”. Important Note: a separate “Workflows” menu also lives under “Content Modeling” — it’s the same mechanism, but scoped to Content Model entries instead of Pages. This opens the “Pages” Workflow — every page in this tenant moves through this same path. Right now it reads “Draft”, then has a custom step called “Content Approval”, and then “Published”.Important Note: “Draft” and “Published” are locked, fixed endpoints; everything in between is a “custom step” we define ourselves. This opens the “Pages” Workflow — every page in this tenant moves through this same path. Right now it reads “Draft”, then has a custom step called “Content Approval”, and then “Published”. Important Note: “Draft” and “Published” are locked, fixed endpoints; everything in between is a “custom step” we define ourselves. To add an additional custom step in this Workflow, we’ll click the “Add new custom step” button.All custom steps can be edited, rearranged, and deleted at anytime using the controls on the right of the step. To add an additional custom step in this Workflow, we’ll click the “Add new custom step” button. All custom steps can be edited, rearranged, and deleted at anytime using the controls on the right of the step. For each new Custom Step, we’ll need to enter a “Title”, “Color” - which comes in handy with alerting, as we’ll see - and an optional “Description”. For each new Custom Step, we’ll need to enter a “Title”, “Color” - which comes in handy with alerting, as we’ll see - and an optional “Description”. We’ll also need to define at least one Team assigned to review and approve the step — this is the field that connects everything we just built, although instead of using the “Site Designer” Team, we’ll select the top-level “Admin” Team for sign-off.Important Note: this is the mechanism that determines who gets notified when someone requests a Content Review. When we’ve configured each field in the Custom Step as needed, we’ll click “Save”.Again, we can return to this step and edit it at any time. When we’ve configured each field in the Custom Step as needed, we’ll click “Save”. Again, we can return to this step and edit it at any time. To recap, we configured the Permissions for the Site Designer Role, added that Role to it’s own Team, and then configured a Custom Step within the Pages Workflow, requiring Content Approval for any new Pages or Page edits, which the “Admin” Team will be responsible for.Next, we’ll show how this all comes together. We will be jumping back-and-forth between an Admin role and a Site Designer role, but will point out when that happens. To recap, we configured the Permissions for the Site Designer Role, added that Role to it’s own Team, and then configured a Custom Step within the Pages Workflow, requiring Content Approval for any new Pages or Page edits, which the “Admin” Team will be responsible for. Next, we’ll show how this all comes together. We will be jumping back-and-forth between an Admin role and a Site Designer role, but will point out when that happens. We’ll start with the “Site Designer” Role we just configured. We can see the user on the top right matches the user that had the “Site Designer” Role in the KIBO Admin UI.Important Note: the navigation has been limited for this user — no “Access Management”, no “Audit Logs”, no “Dev Tools”, and a severely limited “Settings” menu — a direct reflection of the Role Permissions we configured earlier. We’ll start with the “Site Designer” Role we just configured. We can see the user on the top right matches the user that had the “Site Designer” Role in the KIBO Admin UI. Important Note: the navigation has been limited for this user — no “Access Management”, no “Audit Logs”, no “Dev Tools”, and a severely limited “Settings” menu — a direct reflection of the Role Permissions we configured earlier. On the Pages menu, we can either create a “New Page” by clicking the button on the top right, or open an existing page.In this example, we’ll edit the existing “About Us” page. On the “About Us” builder page, we’ll drag an “Image” element onto the canvas, above the page’s existing “Recommended Products” section. On the “About Us” builder page, we’ll drag an “Image” element onto the canvas, above the page’s existing “Recommended Products” section. In the Image components “Element” panel on the right, we’ll click the “Select from library” button to choose an image. In the Image components “Element” panel on the right, we’ll click the “Select from library” button to choose an image. This opens the File Manager menu; here, we can upload a new or select an existing image. This opens the File Manager menu; here, we can upload a new or select an existing image. Back on the Page Builder, we can adjust the image’s “Element” and “Style” settings as needed. Back on the Page Builder, we can adjust the image’s “Element” and “Style” settings as needed. Looking at the top right of the Page Builder toolbar, we can see there’s no “Publish” button. This is the Role Permission from earlier made visible: “Site Designer” can build, but the “Publish” and “Unpublish” checkboxes we left unchecked mean that action simply isn’t available to any user in this Role. Looking at the top right of the Page Builder toolbar, we can see there’s no “Publish” button. This is the Role Permission from earlier made visible: “Site Designer” can build, but the “Publish” and “Unpublish” checkboxes we left unchecked mean that action simply isn’t available to any user in this Role. Instead, the users in this Role will click the “Request Review” button. Instead, the users in this Role will click the “Request Review” button. A confirmation prompt will open, where we can confirm the Content Review request. A confirmation prompt will open, where we can confirm the Content Review request. The page now shows a banner reading “This entry is now under review. You can cancel the review request” — with a “Cancel Review Request” option in its place.Notice the color of this banner matches the “Color” we defined in the Custom Workflow Step we configured earlier, confirming we are on that step of the Pages Workflow. The page now shows a banner reading “This entry is now under review. You can cancel the review request” — with a “Cancel Review Request” option in its place. Notice the color of this banner matches the “Color” we defined in the Custom Workflow Step we configured earlier, confirming we are on that step of the Pages Workflow. Clicking “Cancel Review Request” opens a “Cancel Content Review” confirmation, any time a Review Request needs to be pulled back. Clicking “Cancel Review Request” opens a “Cancel Content Review” confirmation, any time a Review Request needs to be pulled back. We’ll now switch back to the full CMS “Admin” Role to see the reviewer’s side of this request. We’ll now switch back to the full CMS “Admin” Role to see the reviewer’s side of this request. In the left nav, we’ll click “Content Reviews”. “Content Reviews” also sits on the Pages menu page, on the bottom left. Clicking either will take you to the same Content Reviews menu. In the left nav, we’ll click “Content Reviews”. “Content Reviews” also sits on the Pages menu page, on the bottom left. Clicking either will take you to the same Content Reviews menu. This is the Content Reviews menu page. It displays all Review Requests, and has columns for the Page “Title”, while also displaying whether the review is for the “Website Builder” or “Content Modeling” section; the user that “Submitted” the request; the Admin it was last “Modified By”; when it was last “Modified”; the corresponding “Workflow”; and the “Status” of the review.The Content Reviews menu page also contains tabs across the top for “All”, “Pending”, “In Review”, “Approved”, and “Rejected”, plus a toggle between “All”, “My Content Reviews”, and “I Can Access” — every review request is listed from across the tenant, filterable by status and by relevance to the user’s Role. We’ll look at a few examples now. This is the Content Reviews menu page. It displays all Review Requests, and has columns for the Page “Title”, while also displaying whether the review is for the “Website Builder” or “Content Modeling” section; the user that “Submitted” the request; the Admin it was last “Modified By”; when it was last “Modified”; the corresponding “Workflow”; and the “Status” of the review. The Content Reviews menu page also contains tabs across the top for “All”, “Pending”, “In Review”, “Approved”, and “Rejected”, plus a toggle between “All”, “My Content Reviews”, and “I Can Access” — every review request is listed from across the tenant, filterable by status and by relevance to the user’s Role. We’ll look at a few examples now. The “All” tabs shows every review request regardless of status. The “All” tabs shows every review request regardless of status. “Rejected” filters down to just the requests that didn’t pass review. “Rejected” filters down to just the requests that didn’t pass review. “My Content Reviews” display all Review Requests for this user. As this user is part of the “Admin” Team, they are not required to submit Review Requests, so this list is empty. “I Can Access” narrows the list to requests this user is eligible to review, based on the Team assignment. “I Can Access” narrows the list to requests this user is eligible to review, based on the Team assignment. For this latest Review Request, we’ll click that row’s “ellipses” menu and select “Open in New Window” to review the page in a new browser tab. For this latest Review Request, we’ll click that row’s “ellipses” menu and select “Open in New Window” to review the page in a new browser tab. This opens the “About Us” page that was just edited. At the top of the page, there is a banner reading “You can start the review for Content Approval”, alongside a “Start Review” button. This opens the “About Us” page that was just edited. At the top of the page, there is a banner reading “You can start the review for Content Approval”, alongside a “Start Review” button. To start the review, we’ll click the “Start Review” button. To start the review, we’ll click the “Start Review” button. A confirmation modal will display to confirm the Page is now actively in review. A confirmation modal will display to confirm the Page is now actively in review. The top banner updates to “This item is currently under Content Approval review”, with “Approve” and “Reject” buttons now available. When we’ve completed a review of the Page content, we’ll click one of these buttons. The top banner updates to “This item is currently under Content Approval review”, with “Approve” and “Reject” buttons now available. When we’ve completed a review of the Page content, we’ll click one of these buttons. We’ll click “Reject” to walk through that path first.A “Reject Content” modal opens, warning that the content author will be notified; we’ll add an optional reason, which is best practice as it will be communicated back to the Site Designer, and then click “Reject Content”. We’ll click “Reject” to walk through that path first. A “Reject Content” modal opens, warning that the content author will be notified; we’ll add an optional reason, which is best practice as it will be communicated back to the Site Designer, and then click “Reject Content”. A “Content Rejected” confirmation follows, confirming all relevant parties have been notified. A “Content Rejected” confirmation follows, confirming all relevant parties have been notified. Back on the Page, the banner now reads “This entry was rejected”, with a “View Comment” option. Back on the Page, the banner now reads “This entry was rejected”, with a “View Comment” option. Clicking “View Comment” shows the rejection reason we entered — the same note the content author will see. Clicking “View Comment” shows the rejection reason we entered — the same note the content author will see. Switching back to the “Site Designer” Role, the same “This entry was rejected” banner appears here too — both sides of a review see the same status in real time. Switching back to the “Site Designer” Role, the same “This entry was rejected” banner appears here too — both sides of a review see the same status in real time. The rejection comment is visible from this side as well, so the author knows exactly what needs to change. The rejection comment is visible from this side as well, so the author knows exactly what needs to change. On the top right, we can click the “New Revision” button to edit the “About Us” page again. A confirmation prompt opens; we’ll confirm to create the new revision. A confirmation prompt opens; we’ll confirm to create the new revision. This reopens the page in Page Builder, still carrying the image we added earlier — ready to be edited before requesting review again. This reopens the page in Page Builder, still carrying the image we added earlier — ready to be edited before requesting review again. In the Image’s “Element” panel on the right, we’ll click the “pencil” icon on the image to reopen File Manager. In the Image’s “Element” panel on the right, we’ll click the “pencil” icon on the image to reopen File Manager. Back in the File Manager, we can upload a new or select an existing image. Back in the File Manager, we can upload a new or select an existing image. Again, we can adjust the new image’s “Element” and “Style” settings as needed. Again, we can adjust the new image’s “Element” and “Style” settings as needed. When we’ve finished editing the new Page Revision, we’ll click “Request Review” again — a “Request Content Review” modal notes that the entry will be locked from further editing once submitted. We’ll click “Request Content Review” to confirm. When we’ve finished editing the new Page Revision, we’ll click “Request Review” again — a “Request Content Review” modal notes that the entry will be locked from further editing once submitted. We’ll click “Request Content Review” to confirm. The Page shows “This entry is now under review” once more, and can again have the Review Canceled if needed. The Page shows “This entry is now under review” once more, and can again have the Review Canceled if needed. Switching back to the “Admin” Role once more, the new request appears in Content Reviews, with a Status of “Pending”. Switching back to the “Admin” Role once more, the new request appears in Content Reviews, with a Status of “Pending”. We’ll open it and click “Start Review”, the same way as before. We’ll open it and click “Start Review”, the same way as before. The same “Content Review Started” confirmation follows. The same “Content Review Started” confirmation follows. This time, we’ll click “Approve”. This time, we’ll click “Approve”. An “Approve Content” modal opens with an optional comment field; we’ll add a note, only later realizing we misspelled the word “Looks”, and click “Approve Content”. An “Approve Content” modal opens with an optional comment field; we’ll add a note, only later realizing we misspelled the word “Looks”, and click “Approve Content”. A “Content Approved” confirmation follows, notifying all relevant parties. A “Content Approved” confirmation follows, notifying all relevant parties. The page now shows “This entry was approved”. The page now shows “This entry was approved”. Still in the “Admin” Role, we’ll click the “back” button to return to the Pages list. Still in the “Admin” Role, we’ll click the “back” button to return to the Pages list. Note, approval alone doesn’t publish the page. From the Pages list, we’ll click the row’s “ellipses” menu, where “Publish” and “Schedule Publish” now both appear as options — a separate, deliberate action that still has to be taken by a Role with publishing rights. Note, approval alone doesn’t publish the page. From the Pages list, we’ll click the row’s “ellipses” menu, where “Publish” and “Schedule Publish” now both appear as options — a separate, deliberate action that still has to be taken by a Role with publishing rights. Switching back to the “Site Designer” Role, the same “This entry was approved” message is visible here too, even though this user still can’t be the one to publish it. Switching back to the “Site Designer” Role, the same “This entry was approved” message is visible here too, even though this user still can’t be the one to publish it. To wrap up, we should mention that the “Site Designer” Role also has its own “Content Reviews” entry in the navigation — the same screen, just scoped to what’s relevant for this Role. We’ll discuss a few examples. To wrap up, we should mention that the “Site Designer” Role also has its own “Content Reviews” entry in the navigation — the same screen, just scoped to what’s relevant for this Role. We’ll discuss a few examples. Just like the “Admin” view, the “All” tab shows the same review history. Just like the “Admin” view, the “All” tab shows the same review history. “My Content Reviews” is populated this time, since Site Designer is the one who actually submitted the requests. “My Content Reviews” is populated this time, since Site Designer is the one who actually submitted the requests. “Approved” filters down to the requests that made it through review successfully. “Approved” filters down to the requests that made it through review successfully. “I Can Access” is empty here — Site Designer isn’t assigned to review or approve anything, only to submit for review, so there’s nothing for this Role to act on. “I Can Access” is empty here — Site Designer isn’t assigned to review or approve anything, only to submit for review, so there’s nothing for this Role to act on.