Additional security

In addition to the rules governing access to the web pages and web files, Dynamics 365 Portals have a number of other constructs that help you manage security for content other than pages and files.

Knowledge articles

Access to knowledge articles can be controlled by the permissions on the relevant pages. For example, denying anonymous access to the Knowledge Base - Article Details page will ensure that the visitors must be signed in before accessing the individual articles.

However, this is an all or nothing approach. To control access to individual articles, Dynamics 365 Portals use Content Access Levels. Content access levels give another level of control separate from web roles to control access to knowledge articles in a portal.

They work by simply associating individual articles with one or more of the available content access levels. Portal users are associated with the content access levels as well. The knowledge article is available to the user when they have common content access levels..


A user can also inherit a content access level if it is assigned to a web role or parent contact. This makes management of content access easier in larger organizations.

To enable content access level filtering, set the value of the KnowledgeManagement/ContentAccessLevel/Enabled site setting to true.

For more information, refer to Manage knowledge articles by using content access levels.

Blogs, ideas, and forums

Blogs, ideas, and forums are accessed using pages with a specific template that allows additional functionality. There are no separate pages for individual blog posts or individual ideas, or forum posts, and security is centralized with some additional constructs to support specific functionality.


Read access to a blog is inherited from read permissions on the blog's parent page. If a user can read the parent web page, they can read the blog and all of its published posts.

Change/Write access to a blog is controlled through the Author Roles relationship. This relationship specifies the web roles that grant authorship permission on the blog. Any portal users associated with any of these roles will be granted the permission to create new posts, edit and delete their own posts, and edit the attributes and settings of the blog itself. For more information, see Create web roles for portals.


Only the specific author of a blog post can edit or delete that post, through the front-side portal editing interface. The author of a post can also see their own unpublished posts, but not those of other authors.


Ideas are published using individual idea forums with number of ideas within each forum that users can vote for. In addition, there is a concept of moderation similar to traditional forum moderation.

Read access to an idea forum can be restricted to certain web roles using the Idea Forums (Read Access) relationship between an idea forum and a web role. Any portal users associated with any of the web roles will be granted access to the idea forum.

Change access to an idea forum is controlled through the Idea Forum (Moderators) relationship. Any portal users associated with any of the web roles will be able to moderate the idea forum.


Similar to the web pages, read access to the forums is permitted by default though users are required to be authenticated to post in the forums.

Access rules can be added by using Forum Access Permissions. These records associate the individual forum and the specific access rights with one or more web roles. The Right property defines the level of access granted to this forum for any of the users in the associated web roles.

  • Restrict Read - Restricts the forum viewing and participation to the associated web roles only. Users not in any of these roles will be denied access to the forum.
  • Grant Change - Allows a user in a web role associated with the rule to moderate the forum. Grant Change takes precedence over Restrict Read.

Forum access permission

Publishing states

Publishing states allow for the definition of a content lifecycle in portals website. At a basic level, a publishing state can determine whether an associated entity should be considered visible/published on a portal. In more complex configurations, they can define a multi-stage process for content review and publishing, with security restrictions on each stage.

Publishing states can be used with web pages, web files, web links, forums, and advertisements.

By default, two publishing states are available: Draft and Published. Draft specifies content that should not be visible to non-content-author users, while Published specifies content that should be visible to all portal users (if there are no other security restrictions).

You can modify the default configuration to meet your specific requirements by adding new states or renaming states. In addition, you can specify Publishing State Transition Rules that would define which web roles are allowed to move pages between the specified states.

For example, you might have a requirement of web pages being reviewed by the legal department prior to publishing them on the web site. To satisfy this requirement, you can add a new Publishing State Legal Review and clear the Is Visible property to make sure that the pages in this state are not visible by default.

Additional publishing states

Then you would add Page State Transition Rules allowing only members of the legal department to move a page from Legal Review to Published stage. Authors would be allowed to move page from Draft to Legal Review only (and back). That would ensure that authors can only submit pages for a review and, after review is complete and the page is approved, it can be published by the authorized users.

In addition, you can associate Web Page Access Control Rules with specific Publishing State. For example, you can grant change to a web role but restrict that grant to the Draft state only. That would ensure that members of that web role can edit draft pages but are unable to alter pages that are published.

For additional considerations and step by step instructions, see Create and manage publishing states.

Comment policy

While this is not a security feature, managing proper commenting policy throughout your portal can increase the site appeal to the visitors and gather valuable feedback.


The page template renders the comments section. Not all templates support comments functionality. For example, Full Page template includes comments functionality while Page with Side Navigation does not.

The comment policy is configurable per page and can be cascaded down the page hierarchy using the Inherit policy option. Comments are recorded using the Feedback entity.

These miscellaneous security options and features provide additional flexibility that allows building robust, flexible portals where security can be configured to satisfy even the most complex business requirements when it comes to content.