This latest set of improvements include:

• The ability to apply permissions to groups of fields within content types. This ensures all fields are populated by authors with appropriate expertise or by users who understand the intended use of those fields.
• Full-text search makes it much easier for content teams to find the items they’re looking for when they don’t already know the name of the content. This makes the process of fixing typos or incorrect information much faster, as users can quickly find the items containing these issues in order to make their updates.
• We’ve also added control over which formatting tags are available within rich text elements for each content type. This reduces the likelihood of content elements conflicting with front-end designs or SEO strategies. Developers will now be able to focus more of their efforts on building engaging experiences rather than stripping away improper formatting.
• Speaking of developers, we’re introducing a great new tool (the Command Line Interface) to help automate the deployment of content models to different environments. This makes it easier to make changes to your content models (and associated content items), and then test them in different environments before deploying to production. 
  To make these improvements possible, we’re also announcing the general availability of version 2 of our Management API. 
• Lastly, we’ve added the ability to include images within content guidelines to better inform authors about how certain fields will be used. For example, it’s now possible to include a screenshot of a web page or collateral to demonstrate exactly where a content component will be displayed when it’s published.

Continue reading below for more details on each of these announcements.

Add Permissions to Content Groups

Content groups can now be restricted according to user roles, making it possible to lock down portions of content items to only those users who are responsible for populating those fields. This simplifies the authoring experience, as contributors will only be able to access the elements that are intended for them.

How does this improve content authoring?
Content items often require multiple contributors to populate fields related to each user’s area of expertise. By combining fields within content groups, they can now be restricted to only appropriate users. This ensures the integrity of your content while also simplifying the authoring experience as content groups can be hidden completely (or displayed as read-only) from users who don’t have access to edit them.

Common Use Cases:

1. Metadata elements are often included in content items, with an SEO expert being the only user qualified to appropriately populate these fields.
2. Subject Matter Experts may be responsible for the fields related to their area of expertise, while copywriters are responsible for the remaining fields—for example, a new product may require a Product Manager to enter technical specifications while less technical information is managed by the Marketing team.
3. External data is sometimes stored within content fields in order to associate an item with information stored in a different system (such as ERP or PIM solutions). It’s important that this data not be altered within the CMS in order to maintain this association.

To get started using permissions on content groups, see our documentation.

Granular access to Content Groups is managed according to user roles

Fix Content Problems Faster with Full-text Search

Stakeholders often find text on their website that needs to be updated or removed due to messaging, accuracy of information, or typos. Full-text search makes it easy to find and update this information when the name of the content item isn’t already known. 

Search results contain items that include the search phrase anywhere within the content. These results are then prioritized according to how prevalent the search phrase is—i.e., appearing in the name ranks higher than being buried in the middle of a paragraph. In cases where the user already knows the name of the item they’re looking for, they can choose to search only the name field to limit their results to the most relevant matches.

How does this improve the ability to find content?
Previously, users could search for content items by name only. While this works fine when the user knows the name of the item they’re looking for, there are many scenarios where someone needs to find an item but doesn’t know its name. In these cases, full-text search will return all items that match the search phrase anywhere in the content – prioritized by how prevalent the phrase appears within that item.

Common Use Cases:

1. It’s now much easier to fix typos or factual errors when somebody sees them on their website. The user can simply copy a few words of content and then perform a full-text search to find the item that needs to be updated.
2. Full-text search can aid in content governance efforts, finding all instances of content that needs to be updated (across any language) in scenarios such as rebranding, changing a product name, or references to former employees.
3. Authors sometimes need to perform an inventory of their existing content to understand how their company has previously discussed a particular topic. Full-text search will allow this person to get a complete picture of what has already been written.

Full-text search provides the option to search entire content items or only the names.

Restrict Formatting in the Rich Text Editor

Customers can control which tags are available for use within the Rich Text Editor across all of their content types. This provides an extra layer of protection during the authoring process by ensuring users don’t include formatting that conflicts with any front-end designs or SEO efforts.

How does this reduce challenges with your websites and apps?
Including certain tags within content items can negatively impact your website, as the formatting they produce may interfere with other components or design elements. By giving administrators control over which tags can be used in each content type, they can "turn off” tags that create issues on the front-end while still enabling your content team to manage the production of this content. 

Common Use Cases:

1. Including multiple H1 tags on a web page can negatively impact SEO efforts. This tag can now be disabled in content items that aren’t being used to generate the header of the page.
2. The formatting of content can sometimes conflict with the design of a web page or other front-end components. In scenarios where this is a concern, authors can be restricted to only use approved tags within their rich text fields.

To configure the rich text editor to your needs, check out our documentation.

Below is the selection of tags allowed in the rich text portion of the “Biography” element.

Command Line Interface (CLI) & General Availability of Management API v2

The Command Line Interface (CLI) lets developers script changes to their content models in order to include these changes as part of their automated deployment process. This tool leverages the latest improvements to the Management API, which added the ability to programmatically update content models and any related items.

How does this improve development and deployment?
Making changes to content models often requires all associated content to be updated as well and may require changes to the application code that displays the content. By scripting the changes to the models and content items, these changes can be deployed along with the application code to a testing environment to ensure everything works correctly. When it’s time to move it to production, the same scripts can be run on that environment as they’ve already proven to produce the desired results.
You can find additional details on GitHub, to get started using the CLI.

Hopefully, you’re as excited as I am about these new capabilities. Of course, if you have your own ideas for great new features to add, we’d love to hear from you!