News in SharePoint is important right, – no news there! It’s a core function of SharePoint, as it provides an essential communication channel for businesses to let their staff know what’s going. From announcing the arrival of new employees, bagging new customers, warning of IT system outages, to the Social Club’s invitation to Drag Queen Bingo, this is all important stuff in shaping an organisation’s ethos and culture, which is why, it quite rightly takes centre stage on the homepage of most Intranet Portals I come across (and I’ve seen a lot of them).

Given the significance of SharePoint news, I am amazed at how Microsoft managed to get this part of their design thinking so wrong! Hang in there, this article is not a SharePoint bashing. Far from it, I love SharePoint; it has provided me with a livelihood for over a quarter of a century!

In this article I will explain what is, in my opinion, wrong with the Microsoft concept for news so we can design a news management system which side-steps or at least mitigates these issues.

News Articles and Site Pages are not the same

Let’s start with my biggest gripe. In SharePoint, news article are same as standard Site Page (technically). The only distinction is that news posts have been set with a flag to say “hey I’m a news article” which then gets picked up by News web parts so that the article can be displayed and accessed by consuming users, typically from the Intranet homepage.

Standard Site pages and News Article are not even a different Content Type which makes it all but impossible to distinguish them from within the Site Pages library. But news articles and standard Site Pages are not the same (conceptually) – they have a decidedly different purpose, let me explain.

Firmament Pages

A standard Site Page is a long standing and permanent (or at least semi-permanent) addition to a site. These pages may simply provide static (but presumably important) content on things like company values, standards, the mission statement, organisational structure and more.

However the best Intranets provide pages that will surface content dynamically, such as an HR page which provides access to a regularly updated list of “positions vacant”, and so provide a reason for users to revisit, more than the once, beyond onboarding. So whilst the page may be static, the page content is continually refreshed.

Once an Intranet is bedded in, the need to add new Site Pages (or to delete obsolete ones) becomes a relatively rare occurrence in my experience. I call these pages Firmament Pages because they provide the structure and organisation of an Intranet and are typically the end points for site or hub navigation and megamenus.

Smaller organisations, might only feel the need for 20 or so of the these Firmament pages but typically, most will end up with somewhere between 50 and 100+ of them. But my point is that once set up, that number doesn’t change much over time, unless something seismic happens, like rapid organisation growth, or a takeover/merger.

News Articles

In contrast news articles are transient information products. They have a short lifecycle, and a busy organisation might generate dozens of these each week. Although new posts are transient information, that doesn’t mean they are not important, nor does it necessarily mean that they can be immediately disposed of, as we might feel obliged to maintain an archive of old news as a reference resource.

The One-Way-Street Problem

Another poor design decision is the way that Site Page can be “promoted” as a news article because it turns out that this is a one-way action. That is to say, once you make a standard site page a new page i.e. you set the magic hidden flag, there is no easy way in the UI to reverse the action – this is totally bonkers!

And to make matters worse, you are actively encouraged to post newly created pages as news – the option is dangled in front of you when you first publish the page.

And the Promote button is prominently shown in the page command bar until someone decides to click it!

If I accidently “promote” a page, the only way to reset things is to either revert to a previous “un-promoted” version and potentially lose other changes I have made, or copy the page and delete the original. Both approaches smack of being an ugly workaround for a poorly thought through idea.

So why store them together?

Technically, I guess it is an attractive idea to store standard pages and news together because of their similarities from a technical perspective. All that is different, is the afore mentions magic flag and a different starter set of, email-friendly, templates for news.

However, from a process and information management perspective mixing these Firmament Site Pages with transient news articles in the same Site Pages library container is a bad idea for several reasons. Let’s explore them.

Uncontrolled Growth

The number of news articles grows rapidly and will continue to grow indefinitely unless a periodic process of culling or archiving is instigated, which rarely happens in my experience.

This means that for larger organisations, the Site Pages library might easily grow beyond the 5K soft limit Microsoft recommend for the maximum number of documents to be stored in a single library. This is like turning on a tap but without a safety overflow!

Wheat from the chaff

Because Site Pages and news article are stored together, it makes it very difficult to find a Firmament page in amongst the myriad of news articles. Not only are they the same Content Type but they don’t even expose the “I’ve been promoted as news” flag as a metadata attribute, so you can’t filter pages or create a filtered view unless you extend the Site Pages library with a custom metadata attribute (which comes with any additional management overhead).

By default, sorting the Firmament pages (wheat) from the news articles (chaff), becomes all but impossible without accessing each page to check its purpose.

Custom Tagging

It seems likely that we might want to extend the set of metadata attributes in the Site Pages library, especially for news articles where you might want to indicate the type of news by assigning a category, such as “New Employee”, “New Customer”, “Social Event” etc., and the source of the news, often referred to as a news channel, such as “People and Culture”, “Sales” and “Social Club” and so on, respectively.

We get a category column with every SharePoint Events list, so why not with news. Other ideas for extending metadata include:

• Release Date: Wouldn’t it be great if we could set a date and time from which the news article would be picked up by News web parts. That way we could prepare them ahead of time and just have them pop-up on the Intranet when appropriate.
• Expires: In a similar vein, how about setting a date and time when this article is no longer relevant. That way, News web parts might decline to show items that are past their sell-by.
• Priority/Highlight: Not all news has the same importance and it would be great if we could tag an item with a priority attribute such as Routine, Priority, Urgent and Flash and then use that as a means to highlight news items, such as provide a different colour border.
• Pinned: We might want to provide a simple Yes/No column to indicate whether an item should appear first in the list of news items.

(These proposed metadata tags are largely intended to address the Bump-Off problem, I describe next, so hang there).

Because Firmament pages and news articles are the same Content Type, you can’t extend the metadata properties for one without affecting the other.

Sure, we could derive new Content Types or you might choose to leave unnecessary properties blank but that’s an ugly work around which I feel might be easily avoided if Microsoft had thought this through better. It’s unnecessarily messy.

The Bump-off Problem

The bump-off problem comes about because Microsoft have failed to recognise that not all news and events have the same importance.

The standard news web part displays items based in their time of publishing and takes zero account that users might want to see a hurricane warning message telling them to head off home early, as a priority preference to the 6 messages just released by IT support, announcing system maintenance windows scheduled for the weekend. If the timing is wrong, the hurricane warning might be shown for only 5 minutes before it is bumped by the deluge of IT announcements.

In the previous section, I proposed extending News and Events with a couple of additional properties that might be used to resolve the bump-off problem.

First, we might use a Pinned column to flag the item as important so that will always remain in the list of news items, at the head of the list, whilst it remains current (within Release and Expiry dates) regardless of what gets pushed out as regular news items.

Second, we might use a Highlight column to drive a visual indicator in the UI, so as to draw user attention. If only we could highlight the hurricane warning in red to make it stand out!

To be fair, Microsoft has recognised this as an issue and have made an attempt to address things.

For a few years now, you can change the order of news items displayed in a web part. By default, items are still displayed based on time of publication, but you can change that in the web part. You can control haw many items to display in a web part and manually reset the order.

Nice idea, but no cigar! I don’t like this for 2 main reasons.

First, this is a web part setting. This prioritisation should to be set on the item i.e. the item needs to be tagged and used by all news web parts which might display it to drive what the user sees. Making this a web part configuration setting will inevitable lead to inconsistency where in some places hurricanes trump routine IT messages but other places they may not!

Secondly, this approach requires manual intervention. I need to continually monitor and manage each web part instance to make sure the bump-off problem doesn’t kick in and tack over. If we can drive this from the data, we can avoid this overhead and issue entirely.

Microsoft, might claim that this approach is flexible and “by design”, and they can argue this all they like, but the reality is that this is yet another poor design decision – don’t be taken in.

Later in the articles I mention Organisational News Sites, and if you set these up, it provides an additional feature which might help with prioritisation, as it allows news items to be “Boosted”. This feature is aimed mainly at the Viva Connections experience and for auto-generated news digests but when displayed in a web part, a boosted item does get some level of prioritisation. Copilot describes this as a “weighting” and not a universal pin and directs us to this article Boost SharePoint news from organization news sites – Microsoft Support.

Boosted news does show slightly differently in the UI but I most certainly don’t get the option to border it in a bright highlight colour so as to grab user attention.

Permissions

This one is the killer! The people who you want to manage your Firmament pages are not likely to be the same people who you want to create and manage news articles. News might need to be managed by a Communications team who have no business updating say IT support pages, and should not have permissions to do so either!

In the Site Pages library, all pages are stored as a flat list at the top-level (root) folder and so the only way to distinguish access control is to set unique permissions for each page/article, but that goes against Microsoft best practice. It results in significant performance degradation and is notoriously difficult to manage. Setting item-level permissions should be a last resort, used by exception, rather than by rule!

Separate libraries perhaps?

The logical way to resolve this permissions crisis would be to split the content into separate containers. Ideally we would use the Site Pages library for Firmament page and a separate News Pages library for news. Logical yes, but you can’t do it! There is one, and only one, place in which you can save pages, regardless of their purpose, and that is the Site Page library.

This is not how things used to be. In the world of Classic SharePoint, you could create as many Wiki Page libraries as you wanted. Not so in SharePoint Modern, you get a single Site Pages library for everything.

I can’t fathom Microsoft’s logic for constraining us this way – after all that’s not how things were done in the past. Id’ be delighted if someone could explain the rationale behind this limitation.

No, how about separate folders?

Ok, if we can’t have separate libraries, what about separate folders? Folders are securable containers, might we configure the Site Pages library with 2 top-level folders, one for our Firmament pages and the other for news?

Folder-level permissions is potentially a good idea in theory, but sadly it is not a practical solution. The problem is that whenever you use New menu from the site homepage to create a new page (regardless of whether it is a standard Site Page or a news article) it results in pages being created in the root folder of the Site Pages library.

The New menu takes you to the new Templates gallery where you can select you preferred start point.

It seems that Microsoft didn’t even entertain the scenario of creating pages in folders, expect for the Templates folder which is automatically provisioned when needed. This is indicated by the fact that folders are disabled by default on Site Pages, and need to be explicitly enabled to make the option available.

Even when you do enable and create folders, you can’t create pages in the same way from the library New menu, as that method bypasses the Template gallery. Instead you only get access to the legacy menu, which either allows you to create old-school classic pages or a blank modern site page.

Ok, how about if we accept that we can only create pages at the root, can’t we then simply move them into the correct folder immediately after they are created?

Nope, drag and drop is disabled on Site Pages and so is the Move to function. The best you can do is copy the page to a suitable folder and then delete the original. Only then do we end up with our desired outcome where pages and articles are correctly governed by permissions set at the parent folder. But if you create a new article and mail it out at the point of creation (as we are encouraged to do so), that would break the link, so you’re stuffed!

In my opinion this multistep process is too convoluted and fragile to be a workable solution and it makes me somewhat uneasy to entertain such an off-piste scenario that Microsoft clearly never envisaged, meaning it is probably not thoroughly tested.

What about events?

News articles and event lists items are much more closely related than news and standard site pages. They are both transient information products, and after all, an event is really just a news item with an associated time and place!

But events are treated differently. They are not documents in the way that site pages are, but rather they are list items which get rendered in the Modern UX, .

And you can have multiple Events lists in the same site and they can all be secured differently so that People and Culture can manage one events list and the Comms team can manage the corporate calendar.

So how about if we don’t create news pages at all and just create events instead. That would be great from a governance perspective but sadly has some downsides.

• Dates, Times and Locations: These data columns are an integral part of Event lists and at a minimum, all events need a start date value. The problem is that not all news has a start date (or an end date, or a location for that matter).
• No Templates: There is no such thing as an event page templates. The layout and structure is fixed. The best you can do is set a custom image in the header and body content text.
• No Dynamic Page Content: Although Events look like modern site pages, they are not. You can’t add custom web parts or the like, which is a real constraint on their utility.

I think these constraints outweigh any benefits so we are back to needing Site Pages library if we want fully-fledged news.

The Case for News Hub Sites

I hesitated before using the term Hub, as in SharePoint-land this implies a Hub site and that is not what I am talking about. Rather, what I mean by News Hub is a site dedicated to managing news (and events).

Microsoft actively promote this idea (sort of) and so I claim that the pattern is in line with their best practice guidance (Guided walkthrough – Setting up news for your organization using a hub site – SharePoint in Microsoft 365).

Indeed, this article suggested a decentralised approach where there might include several Department News sites and a Corporate News site.

The part that I am not so keen on is that in this article Microsoft, seeks to aggregate news from departmental spoke sites in a Hub but keep corporate news in its one separate site, not part of the hub.

The argument for having a separate Corporate News site is that we can use a PowerShell command to designate this site as an “official” news repository and when we do so, news articles get “emphasized” with a banner like the ones highlighted in the screenshot below:

Using the Microsoft approach we end up in an Intranet homepage (or news page) where news is delivered through 2 distinct web parts, which might be considered as channels, namely Corporate News and All News (by which they mean all other news aggregated from hub sites i.e. Sales and Human Resources in the screenshot below).

Sorry Microsoft but this pattern sucks!

I don’t want news to be fed by two (or more) distinct web parts, just so I can have an “emphasis” badge on one set. And what about when I want to bring in Events (that’s news as well). With that scenario, I end up with even more web parts. If we follow the same pattern for Events we might have rolled up hub events web part and a separate Corporate Events web part, meaning our page now has (at least) 4 web parts.

I do like it that the standard News Web part can be configured so that it is hidden when there is no news to show, but with this pattern (side-by-side) web parts, it will leave an ugly gapping whole in my page when there is no news to display.

Things are worse with the Events web part which doesn’t even have the option to be hidden when there are no events.

So what do I want?

An excellent question, and I’m glad you asked.

Ideally, I want Microsoft to rethink this whole concept from the ground up and recognise that Site Pages and News Articles are two distinct entities. They might technically be similar, but their purpose, lifecycle, security needs, management and governance are so different that lumping them together with standard site pages becomes an absurd idea – separate them please.

If you are going to lump anything together, it makes far more sense to merge News and Events. Conceptually, an event is just a news item with an associated time and place.

I want to be able to set things up so I can have news delivered through a single web part in a configuration of my choosing. I want to create news Channels that might come from a department, a project team, a corporate comms site, the CEO’s office and I want events to be in there as well.

We do need a way to distinguish between news channels (through badging) and provide a way to separate them so we might focus on a single channel but I also might want to see the latest news regardless of channel.

Whilst I am on a roll I’d also want a way to pin and highlight news article so that they remain a priority listing and can indicate some level of importance to end users. But this needs to be driven by the metadata of the news and event items and not by customisation settings in web parts.

I also think we could do better with the layouts options for news web parts. How about a Hero layout where each hero element is a rotating news channel. Or what about a rotating news banner option which can be added to the top of the page in a full width section.

And that brings me to my final gripe. When you click on News or Event items in the standard web parts, the user is simply redirected to page. In a decentralised news management architecture, as Microsoft propose, this means jerking the user off (so to speak) to a different site. This is disorientating and relies on users understanding that they need to use the back button in their browser to get back to where they were. Sadly, this is another poor design decision.

I am not so naïve to think..

That Microsoft will listen to little ol’ me and embark on a heavy weight exercise to re-engineer things and so I have resigned myself to being stuck with what have got – news and site pages lumped together with events shoved off to the side.

That means we need to embrace a certain element of pragmatism and reconcile ourselves that we need to make the best of what we have got to work with.

This means we should set up sites dedicated to news management, which is exactly what Microsoft advocate as best practice. But, as I have pointed out, their guidance leaves gapping holes which cannot easy be worked around if we are constrained by the capabilities (or lack of) provided by the standard News and Events web parts – we can do better than that.

More than just a Hue and Cry

I am acutely aware this post has presented a litany of complaints and poor design decisions and whilst I might not be able turn these around, I can tackle the failings of the standard News and Events web parts by building my own as a replacements

In this unicorn web part solution, I will:

• Integrate news and events.
• Provide a way to badge items.
• Gives users a way to consume information by channels.
• Mitigate the bump-off problem be driving what gets displayed where, based on how it is tagged.
• Use that tagging to allow items to be highlighted and pinned.
• Take account of boosted news items.
• Provide configuration options to pop-up items in a dialog or side-panel without jerking them to a different site.
• Augment the standard layouts with new ones that support channels in tabs, rotating sliders, banners and hero options in addition to the standard tiles and cards.

All that and more is the promise of K-News which is in beta with several of our pioneering customers currently and will go on general release from our web site in January 2026 and released in the Microsoft Marketplace subsequently.

Like all Kaboodle products, it will be available under a Freemium license. Meaning that you can just download and use a fulling functional product – you don’t even need to register. You only need to upgrade to a licensed paid version if you decide to unlock advanced feature.