How to Filter SharePoint Online News Posts in Communication Sites (Step-by-Step Guide)

Introduction

SharePoint Online's News feature has become an essential tool for internal communications, helping organizations share updates, announcements, and stories across their workforce. However, as your news content grows, a common challenge emerges: how do you keep everything organized and ensure employees see only the most relevant information?

Imagine your communication site displaying a mix of company-wide announcements, departmental updates, project reports, and blog posts all in one feed. While comprehensive, this approach can overwhelm users and make it difficult to find specific types of content. Department heads want to see only their team's updates, project managers need quick access to status reports, and employees looking for blog content don't want to scroll through unrelated announcements.

The solution is to filter your News web part by category. By organizing your news posts into distinct types such as:

• Blogs
• Departmental updates
• Project news
• Company announcements
• Status reports

You can create targeted news sections that display exactly what your audience needs to see.

In this guide, we'll show you how to filter SharePoint News using the Page Category field—a fully Microsoft-supported method that leverages page properties. This approach requires no custom development, works across multiple sites, and gives you complete control over how news content is organized and displayed throughout your SharePoint environment.

Why Use SharePoint Online to Filter News?

You benefit from filtering:

• Show only relevant News posts.
• Organize content by categories.
• Create sections for your blog.
• Maintain a clean communication site.
• Improve information discoverability.

You may filter News on any page by using information like Page Category.

Requirements

Before you begin, ensure you have:

• A SharePoint communication site
• Site owner or administrator permissions
• Permission to modify the Site Pages library
• At least a few news posts already created (for testing the filter)

Step 1: Establish a Page Category Column in the Site Pages Library

1. Navigate to your Communication Site.
2. Select Site contents.
3. Access Site Pages, hover over it to see visible ellipses, then click on it to see “Setting.”

4. Click Create column and select Choice as the type.
5. Label the column as "Page Category".
6. Add choice values such as:
   • Blog
   • Project Report
   • Status Report
   • General News
   • General Page
   • Announcement
   • News
7. If you want to set a default value, select one; otherwise, leave it blank.
8. Click the "OK" button to create the column.

Important: this column should be established within the Site Pages library – not within any other list or library.

Step 2: Categorize Your News Posts using Page Category

Every News post needs to have a category assigned for filtering purposes.

1. Open any News Post.
2. Select Page details (located at the top-right).
3. Scroll down to page category.
4. Pick a value (for instance, blog).
5. Save your changes (the page will auto-save) or republish if already published.

Step 3: Add the SharePoint News Web Part to Your Page

Navigate to the page where you wish to show filtered News.

1. Select Edit.
2. Click on the plus sign.
3. Search for News.
4. Integrate the News web part.
5. Choose your preferred format (tiles, list, carousel, etc.).

Note: If you have already been on your communication site, then skip the few steps.

Step 4: Apply Filters to the News Web Part Based on Page Category

1. Modify your page.
2. Highlight the News web part.
3. Select the Edit web part option (pencil symbol).

4. Scroll down to Filter.
5. Pick Page properties.

6. In the Property name section, choose: Page category.

7. In the value input field, type or select: Blog.

8. Implement changes.
9. Publish the page.

Now, the News web part will exclusively show entries labeled as “blogs.”

Step 5: Create a Blog Section Utilizing News Filtering (optional)

You can establish a specific blog page by using this filtered News web part.

Example Configuration:

• Page category = Blog

The news web part was adjusted to display solely blog entries.

Unique banner, design, and navigation links.

This provides a comprehensive blog experience within SharePoint Online.

Step 6: Scale Across Multiple Sites (Reusing the Page Category Column)

Once you've successfully set up filtered news on one communication site, you'll likely want to implement the same categorization system across other sites in your organization. The good news: you don't need to recreate the Page Category column from scratch each time.

SharePoint allows you to convert your custom column into a reusable Site Column that can be added to any communication site. This ensures consistency in how news is categorized across your entire SharePoint environment and saves significant setup time.

Benefits of Using Site Columns

• Maintain consistent categorization across all sites
• Save time by avoiding repetitive column creation
• Ensure all sites use the same category values
• Make updates to categories in one place

How to Create and Reuse the Page Category Site Column

Part A: Convert to Site Column (on your original site)

1. Navigate to Site Settings on your source communication site.
2. Under Web Designer Galleries, select Site columns.
3. Click Create.
4. Enter the column name: Page Category.
5. Select type: Choice.
6. Add your choice values (Blog, Announcement, Project News, etc.).
7. Choose an appropriate group or create a new one (e.g., "Custom News Columns").
8. Click OK to save.

Part B: Add Site Column to Other Sites

1. Navigate to the target communication site where you want to use filtering.
2. Go to Site contents.
3. Open Site Pages library settings.
4. Click Add from existing site columns.
5. Locate and select Page Category from the appropriate group.
6. Click Add, then OK.

The Page Category column is now available on the new site with all the same options you configured originally. You can immediately begin categorizing news posts and setting up filtered News web parts following Steps 2-4 from this guide.

Pro Tip: If you need to add new category values later, update the Site Column definition, and the changes will be reflected across all sites using that column.

Frequently Asked Questions (FAQs)

Can I filter SharePoint Online News by category?

Yes, you can filter SharePoint Online News by creating a Page Category column in the Site Pages library and applying it as a filter in the News web part.

What is the Page Category column in SharePoint?

The Page Category column is a custom metadata field added to the Site Pages library that helps categorize news posts such as blogs, announcements, and project updates.

Is filtering SharePoint News using Page Properties supported by Microsoft?

Yes, using Page Properties like Page Category for filtering the News web part is fully supported by Microsoft in SharePoint Online.

Can I reuse the Page Category column across multiple SharePoint sites?

Yes, by creating a Site Column, you can reuse the Page Category column across different communication sites for consistent filtering.

Can I create a blog section in SharePoint using the News web part?

Yes, by filtering the News web part with Page Category set to “Blog,” you can create a dedicated blog section within SharePoint Online.

Does filtering affect existing news posts?

No, existing news posts will appear once you assign them a Page Category value.

Conclusion

Filtering SharePoint Online News using the Page Category column is a powerful yet simple way to organize content and deliver targeted updates to users. By leveraging page properties and the News web part’s built-in filtering capabilities, organizations can create structured blog sections, department-specific news areas, and cleaner communication sites.

This approach is fully supported by Microsoft, scalable across multiple sites, and improves content discoverability without requiring custom development.

With proper categorization in place, SharePoint News becomes a more effective communication tool for your organization.

If you have any questions you can reach out our SharePoint Consulting team here.

Introducing Heft: The Modern Build Tool Replacing Gulp in SharePoint Framework (SPFx)

For a long time, Gulp was the default build tool for SharePoint Framework (SPFx) projects. Developers relied on familiar commands like gulp serve and gulp bundle to compile, package, and deploy their SPFx solutions.

However, as SPFx applications grew in size and complexity, the traditional Gulp-based build system began to struggle with performance, scalability, and long-term maintainability.

To address these challenges, Microsoft introduced Heft - a modern build orchestrator from the Rush Stack ecosystem - and made it the default SPFx build tool starting with SPFx v1.22.

In this article, we’ll explore the differences between SPFx Heft vs Gulp, why Microsoft made the switch, and how Heft improves the modern SharePoint Framework development workflow.

The Gulp Era in SharePoint Framework (SPFx)

In the early days, Gulp handled almost everything in an SPFx project:

• Compiling TypeScript
• Bundling with Webpack
• Running the local dev server
• Packaging .sppkg files
• Automating the build pipeline

Typical workflows looked like this:

gulp serve
gulp bundle --ship
gulp package-solution --ship

For small projects, this worked fine. For large, long-living enterprise solutions, it did not.

Why Gulp Started to Fail

1. Slow Builds at Scale: Gulp runs tasks mostly sequentially, lacks smart caching, and often triggers full rebuilds for small changes. Result: Slow feedback loops and reduced productivity.

2. Fragile gulpfile.js: Task chains become complex, hard to debug, and frequently break during SPFx upgrades. Result: Build scripts harder to maintain than the app.

3. Poor Fit for Monorepos & Enterprise: Gulp wasn’t designed for monorepos, sharing build logic was painful, and dependency conflicts were common. Result: Scaling SPFx across teams became difficult.

4. Weak Type Safety & Debugging: Mostly JavaScript-based with unclear errors and poor traceability across tools. Result: Developers spent more time debugging the toolchain than writing features.

Enter Heft: The Modern SPFx Build Tool

Heft is a modern build orchestrator from Microsoft’s Rush Stack team, built to support large, enterprise-scale TypeScript solutions.

Unlike Gulp, which is a general-purpose task runner, Heft understands how modern development tools relate to one another - including TypeScript, ESLint, Jest, and Webpack.

Heft focuses on:

• Clearly defined build phases
• Plugin-based architecture
• Incremental builds and smart caching
• Parallel execution where possible

SPFx internally uses Heft to handle:

• Compilation
• Bundling
• Linting
• Testing
• Packaging

SPFx Workflow Update: With SPFx v1.22, Gulp is replaced by Heft - but the developer experience remains familiar.

Task	Command
Dev Server	heft start
Production Build	heft build --production
Package	heft package-solution --production

These commands are mapped to standard npm scripts (npm start, npm run build), so day-to-day development workflows remain unchanged.

SPFx Heft vs Gulp: What Actually Changed?

Feature	Gulp	Heft
Build approach	Scripted tasks	Phase-based orchestration
Performance	Slower at scale	Faster with caching & parallelism
Configuration	gulpfile.js	JSON-based configs
Type safety	Limited	Strong
Monorepo support	Weak	Built-in
Debugging	Hard to trace	Clear errors & logs

Deployment: What Did NOT Change

The deployment process remains exactly the same:

• Output is still a .sppkg file
• Deployment still happens via:
• SharePoint App Catalog
• CI/CD pipelines (Azure DevOps, GitHub Actions)

Only the build engine changed - not the deployment process.

Node.js & SPFx Compatibility

• SPFx v1.21.1+ → Node.js 22 LTS
• Older SPFx → Node.js 16 / 18
• SPFx ≤ 1.21 uses the Gulp-based toolchain
• Heft becomes the default starting from SPFx 1.22

Heft officially replaces Gulp starting with SPFx 1.22 onward.

Why Heft Actually Matters

Moving to Heft brings real, practical benefits:

• Faster rebuilds
• Less configuration code
• Fewer breaking changes
• Consistent builds across teams

Less time fighting the build system, more time writing features.

Frequently Asked Questions (FAQs)

What is Heft in SharePoint Framework (SPFx)?

Heft is a modern build orchestrator developed by Microsoft’s Rush Stack team. It replaces the traditional Gulp-based build system in SharePoint Framework (SPFx) starting from version 1.22, providing faster builds, better scalability, and improved developer experience.

Why did Microsoft replace Gulp with Heft in SPFx?

Microsoft replaced Gulp with Heft to improve performance, maintainability, and scalability of SPFx projects. While Gulp worked well for smaller solutions, it struggled with large enterprise applications. Heft introduces incremental builds, parallel execution, and modern tooling integration.

Is Gulp still used in SPFx projects?

Yes, older SPFx versions (up to 1.21) still use the Gulp-based build system. Starting from SPFx version 1.22, Heft is the default build tool for all new and updated projects.

Does Heft change the SPFx deployment process?

No. The deployment process remains unchanged. Developers still generate .sppkg files and deploy them through the SharePoint App Catalog or automated CI/CD pipelines such as Azure DevOps and GitHub Actions.

Which Node.js version should be used with Heft in SPFx?

SPFx version 1.21.1 and later support Node.js 22 LTS, while older SPFx versions typically rely on Node.js 16 or 18 depending on compatibility.

Final Thoughts

Gulp served SPFx well in its early days, but modern enterprise needs demanded something better.

Heft is not just a replacement, it’s an upgrade.

The shift from Gulp to Heft reflects Microsoft’s move toward a faster, and more scalable build system for SharePoint Framework projects.

If you have any questions, reach out to our SharePoint Consulting team here.

Step-by-Step Guide: Convert a SharePoint Site Page to PDF using Power Automate

Converting SharePoint site pages into PDFs can be useful for creating reports, archives, or offline documentation. In this step-by-step guide, we’ll walk through how to automate this process using Power Automate.

Step 1: Create a Power Automate Flow

Start by creating a new Power Automate flow.

You can trigger it manually or configure it to run on a schedule or in response to a specific event, depending on your requirements.

Step 2: Initialise Department Variable

Add an Initialise Variable action to store the department name.

This variable will be used later when creating folders inside your document library.

Step 3: Initialise PDF File Name Variable

Next, create another Initialise Variable to hold the PDF file name that will be generated for each site page.

Step 4: Get Site Pages

Add a Get Files (Properties Only) action and point it to your Site Pages library.

You can apply a Filter Query to limit the results, or leave it blank to fetch all site pages.

Step 5: Apply to Each Site Page

Insert an Apply to Each loop and select the value output from the previous “Get Files” action.

Step 6: Set Department Variable

Inside the loop, set the Department variable using the value from your DepartOwner (or equivalent) column from the “Get Files” action.

💡 Replace the column name if your field name differs.

Step 7: Set PDF File Name Variable

Now, set the PDF file name dynamically using the page title:

concat(items('Apply_to_each')?['Title'], '.pdf')

Step 8: Get Canvas Content from Site Page

Add a Send an HTTP Request to SharePoint action.

Use it to retrieve the canvas content of each site page.

Pass the ID of the page from the “Get Files” action to get its content.

Step 9: Parse Canvas Content

Add a Parse JSON action to interpret the response from the previous HTTP request.

Use the Body output from the “Send an HTTP Request to SharePoint” step.

Step 10: Create a Temporary HTML File in OneDrive

Next, add a Create File action (in OneDrive).

This will temporarily store the HTML version of the site page.

File Name: concat(items('Apply_to_each')?['Title'], '.html')

Step 11: Convert HTML to PDF

Use the Convert File action (OneDrive) to convert the HTML file into a PDF.

Pass the File ID from the previous “Create File” step.

Step 12: Create a Folder in SharePoint

Add a Create New Folder action in your SharePoint Document Library.

Set the Folder Path using your Department variable to organise PDFs by department.

Step 13: Upload the PDF to SharePoint

Add a Create File (SharePoint) action.

This will create the final PDF inside the folder created in the previous step.

Step 14: Delete Temporary HTML File

Finally, clean up the temporary HTML file created in OneDrive.

Add a Delete File (OneDrive) action and pass the File ID from the earlier “Create File” step.

Once your flow is complete, run it manually (or trigger it automatically as configured). Your SharePoint site pages will now be converted into well-organised PDF files stored neatly in your document library.

If you have any questions you can reach out our SharePoint Consulting team here.

Automating Flow Duplication in Power Automate for New SharePoint Site Creations

Introduction:

Setting up workflows in Power Automate can take a lot of time, especially when the same workflows need to be recreated every time a new SharePoint site is created. 

Instead of manually creating the same workflows repeatedly, you can automate the process. This means that whenever a new SharePoint site is created, the necessary workflows are automatically duplicated and configured without any manual intervention. 

In this blog, we will walk through the steps to automatically duplicate Power Automate flows whenever a new SharePoint site is created.

Use case:

One of our clients required that a specific Power Automate flow be automatically replicated whenever a new SharePoint site was created. Manually duplicating the flow each time wasn’t scalable, so we implemented an automated solution. 

Architecture Overview:

Here's a high-level overview of the automation process: 

• Trigger: A new SharePoint site is created. 

• Retrieve: The definition of the existing (source) flow is fetched. 

• Update: The flow definition is modified to align with the new site’s parameters. 

• Recreate: A new flow is created from the modified definition and assigned to the new site.

Step-by-Step Guide to Automating Workflow Duplication

Step 1: Detect New Site Creation

Add a trigger that detects when a new SharePoint site is created.

Step 2: Get the Source Flow(Template Flow)

Use the Power Automate Management connector. 

Add the action "Get Flow" to retrieve the definition of the existing (template) flow. 

This action returns a JSON object containing the flow’s full definition, including triggers, actions, and metadata. 

Step 3: Get Flow Definition and Modify Site-Specific Values

You will now modify the values in the flow definition to suit the new site. 

Update the flow definition retrieved from the "Get Flow" action by replacing the template’s Site URL and List Name or Library ID with the values from the newly created SharePoint site. 

In Power Automate, this is typically accessed using dynamic content like

string(body('Get_Flow')?['properties']['definition'])

 

Step 4: Get All Connection References

Use the "Select" action to format the connection references by mapping fields like connectionName, id, and source from the connectionReferences array, These will be used when creating the new flow.

 

 

Step 5: Create New Flow in Target Environment

Use the "Create Flow" action from the Power Automate Management connector to create the new flow using the modified definition and updated connection references.

Environment Name: Choose your environment

Flow Display Name: Provide a unique name

Flow Definition: Pass the modified JSON definition from Step 3

Flow State: Set this to control whether the flow is turned on/off after creation

connectionReferences: Pass the formatted connection references from Step 4

Conclusion:

This blog demonstrated how to automate the creation of workflows in Power Automate by duplicating an existing flow. By implementing this automation, you can eliminate repetitive manual setup each time a new SharePoint site is created. This approach not only saves time and reduces the chance of errors but also ensures consistency across all sites.

If you have any questions you can reach out our SharePoint Consulting team here.