What is the Content Blocks EAP and how do I use it?

Hello - will it be possible to change visibility permissions on content blocks? My use case for an example is - I have an article that would be visible to Everyone, but I want to add a section (content block) to it that is only visible to Agents and Logged in Users instead of writing 2 articles. 

I've upvoted Kelsey's suggestion.  It would be great if there was user segment control on content blocks to selectively hide/show content based on who the user is. 

I can see some of these blocks not necessarily being repeated across articles, but just notes that need to be included internally about the specific article, so I'd want to consider an alternative block type that is more about style or permissions that could be used to wrap content to add alternative style guidelines or visibility around it. 

I might have a block that wraps internal only content so that it's only visible to my Agents and Managers user segment, or I might have a block that wraps a Note callout similar to the notes found in this article that allows for a way for formatting styles to be saved without theme or source code modifications. 

Thanks for the feedback Kelsey and Dan!

Right now, we're supporting the reuse of content with the same visibility permissions as the main article. Thanks for going into detail on how you'd use it with permissions. We imagine this being the first step in a number of features around content blocks. The new architecture that underlies these features will allow us to also add visibility permissions in the future.

Additionally adding styled components is something we want to add as well, @Dan Cooper. Do you have theme styles for any components like this today? If we gave you an ability to apply CSS classes via the Editor would that enable you to style a block the way you're talking about?

We'll take this feedback into consideration as we consider priority for the ongoing roadmap of improvements.

I'm curious, have you been able to find use cases for content blocks with the current functionality?

Thanks again for the feedback!

@Ryan McGrew, my team is just getting ramped up on using Guide for content creation now (previously we had an implementation setup that did Github publishing via the API).  

I would be most interested in showing content by user segment.  For example, if I could have an article that covered a customers specific support offering that was controlled by the user segments they were a part of, that would be really helpful to have one article that showed a customer their specific terms without having to maintain multiple articles. 

In addition, having sections of the article available for internal notes would be useful for an agent to get additional context to reduce the need for internal and external articles needing to be written. The primary thing here would be that the internal content wasn't added to the page on load (even in the source code) if the customer wasn't permitted to see the content. 

With either of the above, I'd need to be able to display the customer version to the agent in some way in the knowledge capture app or the Help Center to help indicate that some content may be different in the customer's version and what the agent is seeing. 

As for styling, that one is actually less of a concern for me personally today, but I was a manager that ran a knowledge program through Guide a few years back, we implemented a style block system that my team and I submitted as tips in the community that cover the use cases more.  CSS Styling exists today for this, but it wasn't until I could abstract the CSS code away from the team that it really became standard practice to use those styling blocks. 

Just wanted to add to Dan's comment, that I too agree on this part:

"In addition, having sections of the article available for internal notes would be useful for an agent to get additional context to reduce the need for internal and external articles needing to be written. The primary thing here would be that the internal content wasn't added to the page on load (even in the source code) if the customer wasn't permitted to see the content. 

With either of the above, I'd need to be able to display the customer version to the agent in some way in the knowledge capture app or the Help Center to help indicate that some content may be different in the customer's version and what the agent is seeing."

Thanks for the additional context @Kelsey Davis and @Dan Cooper. I'm curious if you see use cases around reusing content outside of the "internal" note type of functionality you've described above.

Would definitely be using the Content Blocks as currently planned too. We have products that need to have information spanning multiple HCs and we have products that share the same disclaimers so would need to copy and paste and then try and edit all articles - could just edit the content block once. Will need images etc which I understand are to come - assume videos and embeddables too?

I'm finding it easy to branch off of this feature into things that would be nice but don't really fall into "reusable" blocks but the uses I can see are: 

• Links - We have two instances of Guide (non-multibrand) and need the ability to copy content between the two.  It'd be awesome if we could migrate content blocks with our article content and update our content blocks to fix all of our Guide article URLs that exist across all the articles without having to edit each article. This sounds possible inside of a single instance - but I'm curious how this looks for API movement of content. What do Content Blocks do in an API export?  This could also be a different feature request as well.  Given that finding a content block likely is not easy if you have tons of URLs like this - it would be awesome if Guide had these built in for same help-center articles so that an agent could paste a URL in and it automatically became a content block that could be updated later. Looking at JIRA/Confluence as an example where issues and pages smart link to other reference points. 
• Attachments, Images, Videos - It would be great to be able to easy access assets that have been uploaded in Guide for re-use. Great for software UI that could change and we need to update images across all articles.  This looks like it's on the roadmap for videos and images, but attachments would be a good addition here.
• Placeholder-like content (ability to pull data from the user profile, organization, or custom objects).  This would be for providing landing page style articles for customers.  Allowing them to quickly access some data about themselves or their organization.  This could expand to certain guide placeholders like being able to include a curlybars template for a specific form in an article. 

Awesome!

• Links - We're working on better link handling within blocks across in a single instance and across multiple brands right now. However if I understand correctly, you're looking for a a way to sync blocks between 2 instances and preserve link information?
• Attachments, images, videos - These are on the roadmap, we're planning out how we can support this now!
• Placeholder - This is also really interesting and something we've talked about. How would you see your team using this? How would you want to the handle this type of block if the user isn't logged in and we couldn't fetch user information for example? Not show it? Have an alternate block presented?

For links, my main problem is I want to replicate content between help centers that aren’t on the same instance. I can use the API to download and reupload everything, but I have to fix links and images because any new articles I create in the new instance have a new article ID and subdomain. I can easily fix a subdomain, but fixing article IDs is more tedious. My second instance is a government portal and we’ve restricted what can be integrated to it and multi brand wasn’t an option for me, so anything to ease that transition would be helpful.

For placeholders, I’d probably expect the content to not load. It seems the cleanest, if content doesn’t exist, it should not display in the article. It should show in the edit screen with an ability to preview as a user for testing though (kind of like macro previews today). It would be nice to have an alternative block for blank data though. Like how macros have a text version of the rich text macro. Give an option to display a default content block if the placeholder is blank.

So far enjoying this feature! What's the ETA for including tables? Unless I have missed how that works? Thanks

Great to hear @Kelsey Davis! We're working on image support right now and then we'll be looking at other formatting. Tables and custom classes are definitely at the top of the priority list right now. 

Thanks @Ryan McGrew

@Katarzyna Karpinska

Your post mentions that content blocks may be: "a paragraph, a section heading, a code block, a bulleted list"

Will simple strings also be a supported type of content block?

If yes, will it be possible to seamlessly insert them into the middle of a paragraph? Or are content blocks always enclosed by p tags?

Hi Aaron, as a ZD user like yourself, I can't speak to ZD's future plans, but the way that content blocks are implemented make it seem unlikely that simple strings will be supported any time soon. For more on this, see the final paragraph of the article "Creating and inserting reusable information with content blocks (Guide Enterprise)", including:

> In the source code view, you won't see any HTML code for content blocks, only for your regular text. This is because content blocks live independently in the Help Center. Additionally, you'll only see the HTML code for the chunk of regular text where your cursor is placed, between content blocks.

I see. Thank you @Jonathan March.

Too bad, if true.

In my docs work, I'm frequently wanting to define a small chunk of text like a string (or single bullet point), for insertion in multiple places.

Simply being able to put $myString would be great.

I'll have to experiment when the feature is released. But, if the smallest unit of content turns out to be an entire bulleted list or paragraph, that'll likely be a problem.

I'd like to see inline blocks too.  Taking images as an example.  I might want to include a small image of a button in some documentation that should be inline.  That button UI might change and need to be replaced across multiple articles. 

I don't know how far we'd actually take this use case, but I can see product names, team titles, or commands being listed in steps as inline content blocks.  For example, a new beta product might have articles created ahead of time, but we reference it as PRODUCT (PREVIEW) in all article documentation, but once it's out of preview, we just have to update the content block for that string to OFFICIAL PRODUCT NAME and it propagates everywhere.  I give this example knowing that in most documentation, things will likely just be typed out if it's short, but I can see things being done to try to ensure that certain constant values are as true as we can make them and can be updated immediately. 

For years, there have been requests to support dynamic content in Guide. Easier said than done, I'm sure, but from a user perspective this would seem to be an ideal approach -- sharing the same dynamic content between Support and Guide...

@Aaron Halbert, as @Jonathan March rightly concludes from the article, the initial version of Content Blocks won't offer support for such a small element as strings. But as he also points out, we are aware of the requests regarding some sort of dynamic content and we plan to look into it next year so all the feedback that you've just provided is very useful. 

+10000 on this: 

In addition, having sections of the article available for internal notes would be useful for an agent to get additional context to reduce the need for internal and external articles needing to be written. 

This is a HUGE pain point for me, leading to lots of articles that makes it hard for agents to know where to go. (

The external article has the fluff and explanations which is great for our users, but then I could add a "card" that has quick, to-the-point info on agent's steps to take (for example, how to do this in the support tool, splunk, etc.) 

Any way to layout both internal and external content in one article would be amazing! (even something like the ticket interface - as an "internal note" - doesn't have to be pretty!

@Allison S - I agree strongly with your tangential request for internal notes on Guide articles. I encourage you to leave a comment on the relvant feedback post: https://support.zendesk.com/hc/en-us/community/posts/115008147688-Internal-Comments-on-Guide-Articles

And (though it is off-topic here) I'll take the liberty of repeating my old comment on that post, because I think it's an important principle generally:

> All agent-configurable items that impact the customer ([Guide] articles, triggers, automations, macros, etc) should have internal notes. Likewise for the article revision history. 

Yes! When an article is drafted/archived, an internal warning noting that this specific article is linked in other content/macros would be great! 

I'll comment on the post, thanks, Jonathan!

Hello - is there an update on when we'll be able to add images and tables to the content blocks? I'm stuck at a point where I can't fully roll this out across my Help Centre and am using both content blocks and cross help centre search so have duplicate articles now showing up.

Also looking forward to your response re internal content on articles.

Thanks!

We are trying to understand the customer experience with content blocks EAP and identify needs around missing functionality. If you're interested in participating in this usability validation session, feel free to leave your contact details. 

Hi @Kelsey Davis, we are busy working on adding support for images in CB right now and w think we'll have something for you in Q1. As for support for tables and internal content, that's a bit further in the future.