Tech and me

When Your Agent Writes Code Faster Than You Can Review

2025-09-22T18:02:00.003+02:00

Agentic coding has the promise to unlock a turbocharged workweek, cranking out pull requests faster than any keyboard warrior could manually manage. The real bottleneck isn’t how quickly code appears—it's how quickly humans can keep up with the reviews. If you’re thinking about coasting on those newly liberated hours, beware: the pace is relentless and those who snooze will get lapped. Adapt, hustle, and wield your extra time, or get comfortable watching the leaderboard from the bottom.

PS! I continue to recommend human code reviews and remain open to updating my perspectives as AI evolves :)

Short take: review is the constraint; ship more anyway.

A PR takes ~6 hours to write and 15–20 minutes to review—per reviewer. Agentic coding (Copilot and friends) doesn’t cancel your review policy; it makes it matter. As adoption spreads, you spend more time reviewing and still ship more.
It does not matter if the agentic multiplier is 1.2x, 2x, 4x or more, your team will still benefit. However, when does that flip and review starts choking the flow? Read on.

It doesn’t “flip” mathematically, but in practice review starts choking the flow when mr ≈ 1 — about 10× coding speed with two reviewers (r≈0.097) or ~20× with one (r≈0.049) given 6h/PR and 15–20m per reviewer.

Assumptions (and please argue my assumption data)

One author. We model one‑reviewer and two‑reviewer policies.
Coding per PR ≈ 6h. Review per reviewer ≈ 15–20m. (Yes, short. Keep it that way.)
That gives a review/coding ratio r per reviewer of ~0.042–0.056; we use ~0.049. Two reviewers ≈ double r.
Agentic coding is a multiplier m on coding speed (1.2×, 1.5×, 2×, 3×, 4×).

Light math, heavy impact

Split the week between writing and reviewing. If writing gets m× faster, more PRs arrive, so review minutes go up. A back‑of‑napkin math formula for team throughput vs. today:

gain ≈ m·(1+r) / (1+m·r)

r is total human review time divided by authoring time for a PR. Bigger r → more RAT (Review-Added Tapering): the gains flatten as review effort eats into coding speedups.

Case A — One human reviewer

Throughput climbs, and review time takes a bigger slice of the week, but you have headroom at these review times.

Figure 1 — Team throughput vs. agentic multiplier (one reviewer; 15–20 min sensitivity band).

Figure 2 — Share of team time spent on review (one reviewer).

Case B — Two human reviewers

Two required approvals roughly double review time per PR, so you feel the constraint sooner.

Figure 3 — Team throughput vs. agentic multiplier (two reviewers; sensitivity band).

Figure 4 — Share of team time spent on review (two reviewers).

Clearer throughput tables

Two quick tables; both assume a team of eight and the same PR size/quality.

Table A — Adoption curve (8 people; each adopter is 1.2×)

Adopters (of 8)	Avg multiplier (m̄)	Throughput × (1 reviewer)	Throughput × (2 reviewers)
0	1.000	1.00	1.00
1	1.025	1.02	1.02
2	1.050	1.05	1.05
3	1.075	1.07	1.07
4	1.100	1.09	1.09
5	1.125	1.12	1.11
6	1.150	1.14	1.13
7	1.175	1.17	1.16
8	1.200	1.19	1.18

Table B — Throughput as average team multiplier grows (to 4×)

Avg multiplier (m̄)	Throughput × (1 reviewer)	Throughput × (2 reviewers)
1.0×	1.00×	1.00×
1.2×	1.19×	1.18×
1.5×	1.47×	1.44×
2.0×	1.91×	1.84×
3.0×	2.75×	2.55×
4.0×	3.51×	3.16×

About those “free” minutes

Agentic coding frees time. If it doesn’t become more (or better) PRs, it still has to land somewhere:

Best: quality. More tests, tighter diffs, cleaner commits. Review gets faster when diffs are tidy.
Good: non-code work. Specs, comms, reviews, mentoring—all the glue.
Worst: Xbox/Netflix. Teams that reward shipped work will see the reinvestors lap the coasters.

Push the pivot out

Keep PRs small—cheap to read is cheap to ship.
Let CI and AI do pre-review: lint/tests/security, AI summaries and risk flags.
Block time for review—don’t background it.
Two approvals only when it truly buys risk down.

Bottom line

Manual review doesn’t kill agentic gains. With 6h write / 15–20m per reviewer, one-approval teams have plenty of headroom; two-approval teams still gain but meet the review wall sooner. Convert freed minutes into smaller, better PRs—or more of them— and the meter on shipped work keeps spinning faster.

Governing Feedback Data Sharing in Microsoft 365 Apps and Copilot

2025-08-13T22:02:00.002+02:00

Microsoft treats user feedback as confidential and uses it to improve the product experience. That does, however, involve real people reading what’s submitted. For many organizations that’s fine; for others it’s something they want to control—particularly when feedback is sent from Copilot chat, where a message might contain sensitive business context.

Good news: you can govern what can (and cannot) be sent in the feedback dialog.

Note: Prompts and responses used inside a Copilot conversation are not viewed by Microsoft. What I’m covering here is only the optional feedback form users can submit.

Where to configure Feedback policies

These settings live in the Microsoft 365 Apps admin center as Cloud Policy:

Go to config.office.com → Customization → Policy Management.
Create or edit a policy configuration for Microsoft 365 Apps and scope it to the users/groups you want.
Search for Feedback to find the policies below.

Official docs for Cloud Policy: https://learn.microsoft.com/microsoft-365-apps/admin-center/overview-cloud-policy.

These policies apply to apps and web experiences that use the standard “Send feedback to Microsoft” UX from Microsoft 365 Apps (including Copilot surfaces that use that dialog). Teams uses its own policy model for feedback, so manage Teams separately.

Also important: these settings are not “restrictive by default.” If you don’t explicitly disable them, users can include logs and content samples by default.

See https://learn.microsoft.com/en-us/microsoft-365/admin/manage/manage-feedback-ms-org for a list of products covered by feedback policies set at config.office.com

The four knobs that matter (set to Disabled to restrict)

I’m listing them in the order I recommend you evaluate them.

1) Allow Microsoft to follow up on feedback submitted by users

What changes: the small text at the bottom of the dialog that says Microsoft may contact the user.
Why it matters: disables the consent for follow-up (no contact back). Many orgs prefer no outbound follow-ups to end users.

2) Allow users to include screenshots and attachments when they submit feedback to Microsoft

What changes: hides the Include a screenshot control in the form.
Why it matters: screenshots often contain customer content.
Gotcha: this does not cover log/content attachments (that’s the next policy).

3) Allow users to include log files and relevant content samples when feedback is submitted to Microsoft

What changes: removes the option that shares the prompt, generated response, relevant content samples, and additional log files with the feedback.
Why it matters: this is the big one for Copilot. When enabled, users can (and by default will) include parts of the conversation and context data. Setting it to Disabled prevents those from being sent.

4) Allow users to submit feedback to Microsoft

What changes: blocks the feedback dialog from appearing at all.
Why it matters: the nuclear option. If you don’t want any feedback sent from the product UI, turn this off.

What users will see

Here’s how the UI shifts as you apply the policies:

With default settings, users can add a screenshot and (by default) include prompt/response + logs/content samples.
Disable follow-up → the small “Microsoft may contact you…” text is removed/changed.
Disable screenshots → the screenshot checkbox/button disappears (users cannot attach images), but log/content sharing may still be available unless you disable it too.
Disable log files and content samples → the “Share prompt, generated response, … and additional log files” option is removed, so no conversation context is shared.
Disable submit feedback → the dialog doesn’t show.

Recommended approaches

Pick the level that matches your risk tolerance:

Leave as is: The default behavior allows Microsoft to capture valuable feedback to adjust products and experiences to the better for those using them.
Balanced: Disable screenshots and log files/content samples, allow feedback, and optionally disable follow-ups.
Strict: Disable screenshots, log files/content samples, and follow-ups.
Locked down: Disable submit feedback entirely.

If you do allow feedback, you may want to consider disabling the log files and relevant content samples option for Copilot users. While this data is handled securely by Microsoft, turning it off can help ensure that no conversation snippets or contextual information are included in feedback—something some organizations prefer for peace of mind or to align with their internal data handling practices.

Final thoughts

I work at Microsoft, and I know there are actual people reading feedback to make our products better. That’s a feature, not a bug—but each organization has different requirements for customer data. With Cloud Policy you can decide what’s appropriate for your tenant, from light filtering to full lockdown.

Again, this doesn’t change how Copilot processes prompts during normal use—those aren’t viewed by Microsoft. We’re only talking about the separate, optional act of sending product feedback according to your level of comfort, and is why the options are there.

If you’ve got a mixed environment (e.g., Teams), remember to set feedback controls where that app expects them.

Happy governing!

Taming the Context-Switch Hydra: How an AI Sidekick Saved My Sanity

2025-05-27T11:36:00.000+02:00

TL;DR:

GitHub Copilot (in Agent mode with Codespaces) dramatically cuts down the cost of context switching, perfectly fitting my chaotic, multitasking workstyle. It lets me stay productive and in flow, even as I juggle coding, helping others, and specs—all while being 51 and still loving the craft.

For Those Who Prefer the Director’s Cut …keep on reading

One small step for SharePoint intranets, one giant leap for news roll-up

2024-07-08T10:15:00.002+02:00

..well, not really, but it’s an improvement which makes news roll-up match multiple information architecture scenarios. I’ll leave it up to those setting up intranets to gage the usefulness, and I know there has been demand for this feature.

A shoutout to my old peeps at Puzzlepart for wanting this feature – adding to many other customers who have asked for this feature.

So, what am I talking about? In the news web part, when you use “Select sites” or “Recommended for the current user”, a new option to either show or hide the site title will show below the sites you pick.

When displaying news from one site, the site title is already hidden as you are on that one site anyways. If you pick more sites, you may want to hide the site title because content authoring happens in multiple sites because of information architecture, not because you need to show the site title.

Here’s an example with and without site titles.

Happy intranet authoring!

What’s great at Microsoft, is that anyone can contribute anywhere. The above feature was implemented by yours sincerely as part of one of the yearly hackathons we have at Microsoft. It allowed me to look more closely at how web parts are built in SharePoint, and also solve a customer pain. Win-win!

Search nugget: The beauty of SharePoint Site Columns

2024-06-25T09:15:00.001+02:00

The scenario I’m sharing is not a new one, but (somewhat) recent changes to SharePoint indexing of items may make the scenario easier to solve.

Before we dig into the details, let's talk about Microsoft Syntex, as it has bearing on the nugget I will share. Microsoft Syntex is a service that uses AI and machine learning to automatically sort and classify documents across SharePoint, Microsoft Teams, OneDrive for Business, and Exchange.

Or simply put in terms for SharePoint: Pulling structured data out from unstructured data and store it as metadata for easier use and retrieval. Something we have done manually or via customized processed for the longest time in SharePoint lists and libraries.

Microsoft Syntex is licensed via a pay-as-uou go model, where you pay for items processed. See https://learn.microsoft.com/en-us/microsoft-365/syntex/syntex-pay-as-you-go-services and for more details and the offering currently includes these features:

Prebuilt document processing
Structured and freeform document processing
Unstructured document processing
Autofill columns
Content assembly
Image tagging
Taxonomy tagging
SharePoint eSignature
Document translation
Optical character recognition (OCR)
Microsoft 365 Archive
Microsoft 365 Backup (Preview)
Microsoft 365 Backup Storage (Preview)

A Microsoft Syntex enabled library also enable a better context query user experience. See https://learn.microsoft.com/en-us/microsoft-365/syntex/metadata-search for details.

Let's get to it!

Say you have a library where you add a new column. In this case a number column.

In a search scenario for the library you want to filter results based on the number value. One example being all items with a value above 100.

In my case the column has an internal name of PnPNumberColumn. If the column was manually created at the library it would output a crawled property named ows_PnPNumberColumn. This crawled property could be mapped to RefinableInt00 and after re-indexing you could use the below KQL query to list all items with a value above 100. If you add an alias to the managed property you could use this instead.

RefinableInt00>100

Now, let us go back to the site column scenario. Site columns will in addition to the default crawled property, create an additional crawled property and an automatic managed property. This is described at Automatically created managed properties in SharePoint Server which also apply to SharePoint Online despite what the article is tagged as.

The caveat of the automatically created managed properties is that they are of type text, which is not very useful when it comes to numbers. The example column above yields an automatic managed property named PnPNumberColumnOWSNMBR. This means I can query with:

PnPNumberColumnOWSNMBR:500 or PnPNumberColumnOWSNMBR=500 and get a match, as it matches on text. PnPNumberColumnOWSNMBR>500 would however be invalid KQL.

And here is the nugget. In addition to PnPNumberColumnOWSNMBR we now also get an additional property PnPNumberColumnOWSTNMBR. Note the extra T.

A word from our sponsor: This tip was brought to you by indexing advancements made for Microsoft Syntex. Microsoft Syntex greatly automates creation of site column for the average user. What are you waiting for?

And don’t be fooled by the schema admin page saying the property is of type text, as it is indeed of type number. A fact somewhat called out in a notice when you view the property settings, so you just have to trust me.

Below is screenshot showcasing the behavior where the query PnPNumberColumnOWSTNMBR>499 return the sample document. Easy as pie!

PS! The property is not refinable so you can not use it as refinement filter. If this is your case keep on as you always have and map to e.g RefinableInt00

00000101

2024-06-06T15:09:00.001+02:00

How time flies! I have now been 5 years at Microsoft. I started as a Program Manager, which changed into Product Manager, and now I’m an Engineer.

Despite the title changes the work I do has not changed much over these five years. I have always been a jack of many trades, and I enjoying doing many things at once. When everything is interesting and challenging, it is hard to cut something out. And I have been lucky to be allowed to work to my strengths while still learning – and I love to learn!

What has changed over the years is that I have learned to appreciate process and governance more than before. Which is why I have onboarded to internal roles as privacy champ, compliance champ and responsible AI champ – the last one becoming increasingly important as Microsoft focus all energy on Copilot. Luckily for me loving search as a function and search tech, is that Microsoft Search plays an important role also in Copilot.

What the next one or five years will bring I have no idea, and it’s not important. I’m still a day to day kind of person, with no long term plans. If what I do is fun, challenging and benefits Microsoft customers, I will keep doing it. And for those who know me, I’m not giving up om my long term mission to cut ties from classic SharePoint search features still having dependencies in the modern world of Microsoft Search. Some cuts are hard but still important to ensure the success of future experiences.

Cake time!

Copilot Productivity Tip – Structured formatting in Word

2024-03-27T10:40:00.000+01:00

Time spent per day before: 15 minutes per document
Time spent with Copilot: 5 minutes per document

Resources

Taking my previous post about re-writing text in Word, we can prompt to have key points from the text pulled out and as an example formatted as a table for easier consumption.

The prompt used is “Extract key points into a table with two columns for key point header and details”, and the output is the table below.

Key point	Details
Copilot can rewrite the content	Copilot can check and improve the tense, the passive voice, the readability, and the personal tone of the content.
Copilot may or may not respect the writer's style	Copilot's suggestions may vary depending on the instructions given by the writer. The writer can try to specify the style they want and see what Copilot does.

Copilot Productivity Tip – Word re-write

2024-03-22T10:35:00.008+01:00

Time spent per day before: 30-60 minutes per document
Time spent with Copilot: 5-10 minutes per document

Resources

Writing in a language that is not one's own can be challenging. That is why Copilot can help rewrite the content to make it more consistent and clear. Copilot can correct the tense, the passive voice, the readability, and the personal tone of the content. This way readers can enjoy the content more and understand the main points better.

Some writers may have a specific style that they want to use. Copilot in Word may or may not respect that style, depending on the instructions given. But one can always try to tell Copilot what kind of style they want and see what happens. Maybe Copilot will surprise them with some creative suggestions. Or maybe Copilot will ignore them and do whatever it wants. Who knows?

Original draft

Here’s the original blog-post I started out with before throwing Copilot at it.

Not everyone is a native writer of the language they produce content in. Thus, using Copilot to rewrite your content for consistency in terms of tense, passive language, readability, and personal flavor will ensure those consuming the content have a better experience and more clearly pick up on the points you want to come across in your argumentation.

If you have a particular writing style, then Copilot in Word may or may not be able to assist, but you can try to add this as part of the prompting instructions and verify the outcome.

Automatic rewrite

When using the auto rewrite feature this is what I ended up with.

Sometimes, people write content in a language that is not their native one. Therefore, using Copilot to edit your content for consistency in grammar, voice, clarity, and tone will help those who read the content have a better experience and understand the messages you want to convey in your reasoning.

If you prefer a specific writing style, then Copilot in Word may or may not help you, but you can attempt to include this in the prompting instructions and check the result.

Manual prompt for rewrite

This time around I wanted to give more instructions to simplify my writing.

“Rewrite the text using shorter sentences and language understood by an audience with little experience in Copilot or Word. Make instructions concise and relatable for beginners.“

Do you write in a language that is not your first one? Then Copilot can help you make your writing better. It can fix grammar mistakes, make sentences easier to read, and use the right words for your message.

Do you have a favorite way of writing? Copilot in Word might be able to copy it. Just tell it what you want and see what it does. You can always change it if you don't like it.

Manual prompt with styling

And this is the prompt I ended up with for the final post, as it reflects some of my personal writing style. Maybe this will makes it way into Word eventually using writing samples for style.

“Rewrite the text using shorter sentences and language understood by an audience with little experience in Copilot or Word. Make the text longer than the original, write in third-person tense and **DO NOT** use *I*, *You*, *Your* and *We*. Throw in some subtle irony and sarcasm.”

Copilot Productivity Tip – Teams Message Rewrite

2024-03-20T10:29:00.010+01:00

Time spent per day before: 10 minutes, rethinking the words to use
Time spent with Copilot: 1-2 minutes, letting Copilot do the work

Resources

Rewrite and adjust your messages with Copilot in Microsoft Teams

One of the challenges when writing is to convey feelings or emotion on what you type. I like to be short and concise in my messaging, but sometimes this may not be the best way to communicate when talking to people you don't know, or even people you know.

Let’s take the message “I don’t agree with your points” and run it thru Copilot to make it longer and Enthusiastic.

The output can be something like: “Thank you for sharing your perspective. However, I have a different view on the matter and I would like to explain why I disagree with some of the points you made.” which is less likely to piss Vesa off :)

You can even do a customized prompt for formatting: “Make it sound like it was written by Super Mario”. The above prompt is actually a prompt hack to overcome Responsible AI to add some Paolo Italian flavor into the message.

Copilot Productivity Tip – Teams Chat Catchup

2024-03-18T10:28:00.014+01:00

Time spent per day before: 30-60 minutes
Time spent with Copilot: 5-15 minutes

Resources

Use Copilot in Microsoft Teams chat and channels (video)

My workday at Microsoft involves communication with multiple teams spread around the globe, which means in-person communication is not always possible. This is why Teams has become the go-to tool for many conversations and discussions. When I start my day at 8am in the morning I know chats has happened in other time zones, and instead of reading everything right away I can use Copilot catchup for a summary, and then decide if I need to read it all.

I typically use the “Summarize what I've missed” Copilot suggested prompt inline in the chat which opens the Copilot pane, or I open the pane manually as seen below with prompts such as “Highlights from the past day” or “Highlights from the past 7 days”.

Copilot Productivity Tip – Teams Meeting Insights

2024-03-15T10:42:00.000+01:00

Time spent per day before: 0-120 minutes

Time spent with Copilot: 0-15 minutes

Resources

The beauty of online meetings with transcripts is the ability to quickly go back and find key points later without having to watch the recording or read thru the full transcript.

By default Teams provides an AI notes section with a quick summary, and using the Copilot pane you can ask more direct questions such as summarizing your talking points, or ask what your action items were for the meeting.

My best example is a late night meeting where I forgot to take notes and the next morning I knew I was supposed to contact an “Andrew”, but had forgotten the full name. Requesting the name in the meetings Copilot quickly gave me the name, saving me around 15 minutes and some grief.

Allowing arbitrary custom scripting in SharePoint Online, or not? – that is the question! (aka Stealing your data since 2001!)

2024-03-08T17:12:00.002+01:00

…and the answer is, as it always has been, NO!

Disclaimer: the opinions of this post are mine entirely, and nothing to do with my work at Microsoft. I have not changed opinion on this matter in the past many many years.

Sparked by the recent message center post MC714186 – Remove Custom Script setting in OneDrive and SharePoint web, I figured I’d write out my stance and my full support of the planned change.

Summary: The Custom Script setting in OneDrive and SharePoint web will be removed in March 2024. A new PowerShell command, "DelayDenyAddAndCustomizePagesEnforcement", has been introduced to delay the change to custom script set on the Tenant until mid-November 2024. The NoScriptSite setting will be configured to True for all existing SharePoint sites and OneDrive sites except for specific site templates. Existing scripts in OneDrive and SharePoint sites will remain unaffected. Administrators can permit the execution of custom scripts on specific SharePoint sites using the Set-SPOSite command.

In the above summary I want to point out that “existing scripts will remain unaffected” means classic page injections. Not SPFx solutions on with the setting requiresCustomScript=true.

The challenge

SharePoint by design is a JavaScript application and has always allowed for extensibility in the UX. In modern ways extensibility is achieved via the SharePoint Framework (SPFx), which you should use, and that is ok. Because by virtue of how SPFx is built any script or logic in a SPFx solution is governed and controlled by design.

To explain what I mean. By arbitrary code I mean someone can insert and freely modify JavaScript that runs in a SharePoint site or page without anyone noticing. One example being a bad actor put script on a page which when a person visit the page then transfers all the persons OneDrive files to evil.corp in the background without the person ever knowing. And this has been possible with SharePoint in classic experiences since always, and also with 3p modern webparts when allowing script to run, or by bypassing settings for a site.

When writing code in a SPFx solution, it is no longer arbitrary. Someone wrote it, built it, and then handed the package over to a person with SharePoint admin role rights to install it (or by an admin role proxy if a site has it’s own app catalog). How diligent the process is for code review and installation is up to each organization, but at least the setup allows for a governed process to help control what is installed into a tenants SharePoint Online experience.

Arbitrary script on the other hand would be JavaScript added to SharePoint sites or pages by any regular user with edit rights or a site administrator. Every Team or Group creator is a site administrator of the associated site, and this is not very controlled in my opinion. With classic SharePoint, script can be injected or allowed via the Script Editor web part, via search display templates, and via something called custom actions. When Modern sites were introduced many years ago, allowing these features were by default turned by setting the “Allow and Customize Pages” permission to false. The feature is more commonly renamed in e.g. PnP PowerShell to NoScriptSite. Documentation on turning this on or off can be found at https://learn.microsoft.com/en-us/sharepoint/allow-or-prevent-custom-script.

Back to the message center post and what changes

In March, the SharePoint admin UX setting to allow custom script on OneDrive sites or self-service sites is going away, and is being replaced by a PowerShell cmdlet function Set-SPOTenant DelayDenyAddAndCustomizePagesEnforcement which you can use until mid-November 2024.
All new and existing sites will be set to block custom scripts unless they were created with any of these web templates: BLANKINTERNETCONTAINER#0, CMSPUBLISHING#0, BLANKINTERNET#0. GROUP#0, APPCATALOG#0, CSPCONTAINER#0.
From mid-November 2024, custom script is disabled for your sites every 24 hours. You can manually re-enable it with for example Set-SPOSite <SiteURL> –DenyAddAndCustomizePages. This means you need to set up a scheduled job every day to re-enable it where needed for SPFx solutions relying on this feature, unless you migrate your ungoverned script solutions to governed ones using SPFx.

Should you be worried?

If you are still on classic pages, then disregard as you are a lost cause anyways. It’s 2024 people! Modern is no longer modern. It is the new classic.

Hopefully most customers have moved over to using SharePoint Framework for any custom JavaScript solution running in SharePoint Online by now. However, the elephant in the room is my infamous Modern Script Editor Web Part- https://github.com/pnp/sp-dev-fx-webparts/blob/main/samples/react-script-editor/README.md. If built without changes then someone has changed the site settings to allow arbitrary script to run for the web part to work. When this is then flipped off every 24 hours by the service, the web part will stop running (which is good!).

Instead of working the web part will render ugly white space instead.

Alternatively you rebuild the web part bypassing the custom script check saying it does not rely on custom script (boooooo on you, and bad governance practice).

It is no secret what my take is on usage of this web part. The sample modern script web part should NEVER be used, and I will argue to my death that there are no good scenarios for it. Sure, it’s quicker to use compared to always creating new SPFx extensions or web parts, but is this ease of use more important than security? My answer is still a big NO! Sure, you may reduce the attack vector by using site scoped app catalogs, and maybe you have the utter most control for who can edit pages in those sites. But is this a long term risk you are willing to take?

Why not just build your scenario solutions in a governed way thus blocking someone from changing the code? If you have access to someone building the Modern Script Editor web part, then you also have access to someone who can do it the right way.

What now?

My hope is that people do not run a script every 24h to allow custom script, or that they cheat on building SPFx web parts to bypass scripting. Instead everyone should embrace this opportunity to get their solutions cleaned up – if they haven’t already.

Happy coding governed solution, and preventing your files from being stolen!

Easier editing of Microsoft Search verticals in SharePoint sites (finally fixed!)

2024-01-18T15:34:00.004+01:00

This is perhaps a tiny one, but for the longest time search verticals in a SharePoint site or SharePoint hub site has been a bit of a mystery when you wanted to edit a vertical. To invoke edit, you had to double click the vertical, as there was no Edit button in the ribbon.

The issue has been known since the feature rolled out, but not addressed. I'll be as blunt to say I decided to take matters into my own hands and just fix it. So here you go, a gift from me to allow a more intuitive way of editing search verticals in SharePoint - as the Microsoft 365 Admin center has had the Edit button always.

At last the experience matches the documentation at https://learn.microsoft.com/en-us/microsoftsearch/manage-verticals#manage-site-level-verticals.

Demystifying Author properties on files in SharePoint and search

2024-01-11T12:49:00.034+01:00

For as long as I have been doing SharePoint, figuring out what properties to use when filtering or displaying search results in regards to people has been a challenge as the documentation in this space is somewhat lacking. I’m not sure why I haven’t done this writeup earlier, but no time like the present.

AI model bias and why responsible technology matters – exemplified by image generation

2023-12-08T13:40:00.003+01:00

In this era of AI where ChatGPT with LLM’s has become the hottest topic in computer science since the Apple Macintosh and the IBM PC, I figured I’d do a small write-up on AI model bias and why paying attention to bias is important. This is especially true when it comes to enterprise scenarios where Microsoft is launching a long range of AI powered copilot experiences.

The author of this article works for Microsoft (December 2023) and is an internal champion for responsible ai and technology as well as internal champion for privacy and compliance.

At Microsoft we have a high bar for delivering responsible AI solutions, which means there is a lot of work put in place to ensure the output from AI systems follow Microsoft’s AI principles to be fair, inclusive, reliable and safe, privacy and security is accounted for, and the systems are accountable.

Any model, that be a large language model (LLM) or a model to generate image will inherently have bias built in due to the training data used. In smaller models you can manually verify the training data to counter some bias and balance the training set, but as models grow large this becomes inherently harder. I’m not saying there are not systems in place to counter training bias already, but to truly counter bias this has to be built into pre and post processing of input prompts and outputs from the models.

I will use image generation as an example where I will show the difference between using image creator in Microsoft Designer (https://designer.microsoft.com/) built on DALL·E 3 from OpenAI and Stable Diffusion XL, which is an open source model from Stability.AI (https://stability.ai/). The Microsoft solution has guardrails in place, where the open source solution do not – unless you add them yourself via prompting. Not saying neither of them are perfect as examples will show.

I want to call out that any bias shown is not statistically verified, and only based on generating a set of sample random images with the same prompt.

Example 1 - photo of correctional officer in a well lit hallway eating a donut

The above eight images are from DALL·E 3. They are all close-up photos showing a fit, light skinned male with dark hair.

In comparison the SDXL images have a wider focal point showing the full body. It’s a mix of male and female people, and also a mix of light and dark skinned people. I would argue the SDXL model is more accurate to what people look like in 2023, while the DALL·E 3 model output “perfect” looking people. If this is due to the images the models are trained on, or the prompt being augmenting to have “perfect” looking people I do not know.

The default color palette is also different where DALL·E 3 has more green and SDXL has more brownish colors.

If I add “overweight” to the DALL·E 3 prompt, the Responsible AI filter kicks in and blocks the generation. If I add “fat”, then it works.

With SDXL I can modify the prompt to “closeup photo of a slim white male correctional officer in a well lit hallway eating a donut” to mimic what DALL·E 3 output by default – to counter the wide angle and real life looking people bias of the model.

Example 2 – woman

Let’s try a simple prompt with the subject “woman”. For SDXL I added negative prompting to avoid any nsfw images – which is blocked as part of DALL·E 3 RAI principles.

DALL·E 3 seems to pivot towards portrait photo’s when no extra contextual information is given, as that is likely the intent with a simple input subject. They are also all dark haired and seem to be young women.

In comparison SDXL gives a wide variety of image types, pivoting to more art-like images instead of photos.

Example 3 – painting of a beautiful norwegian fjord with vikings, with a boing 737 in the sky, in the style of munch’s scream

The DALL·E 3 painting nails the airplane and pretty much the painting style of Edward Munch.

The SDXL one is not bad either, but the Munch style is not as visible for this one sample. And the scale of the plane vs. the viking ship and buildings is way off.

Learnings

These simple examples shows that articulating your intent in prompting is crucial. Either the system has to add guardrails and contextual information to the prompt, or the person prompting has to be articulate on what they want returned and what they do not want returned. And you have to generate many images to find that ONE you really like.

For online services like Microsoft Designer going the safe route is the only approach as people using the service comes from a wide variety of backgrounds and age groups. Taking that extra measure to ensure everyone feels safe is important to trusting the service.

Open source solutions you can run on your own PC/phone/table can allow for less guardrails as the individual running it likely has more skill and is using the tool themselves. Maybe the analogy of hiring a carpenter as a service vs. hammering yourself can be used. You trust a hired professional to meet a certain bar, while you are responsible yourself on anything you do.

When it comes LLM’s we know they are largely based on English text today, and would favor input and output in this language. As they are built on public data, that will influence default writing style as well. fortunately ChatGPT and Microsoft Copilots put a lot of effort into the system prompts put around the user prompt, to counter any bias in the model. This is to ensure grounding in facts and avoid hallucinations. More on that for another post.

References

I used the service of https://designer.microsoft.com/image-creator to create the DALL·E 3 images, and I used the Draw Things app on a MacBook with an 8-bit quantized version of the default SDXL model. The Draw Things app also work on iOS devices.

How to paginate large results sets for SharePoint items using the Microsoft Graph Search API

2023-08-10T12:29:00.006+02:00

If you want to paginate over a large set of results for some reason using the Microsoft Graph Search API, you can employ the logic mentioned for the SharePoint API at https://learn.microsoft.com/en-us/sharepoint/dev/general-development/pagination-for-large-result-sets. Note that this option applies to OneDrive and SharePoint items, not necessarily other content sources available via the Graph Search API (not tested).

Use a basic JSON template like below for your search requests, or modify to add other parameters needed for your request.

{
    "requests": [
        {
            "entityTypes": [
                "driveItem"
            ],
            "from": 0,
            "size": 500,
            "query": {
                "queryString": "contoso indexdocid>**LASTID**"
            },
            "fields": [
                "indexdocid"
            ],
            "sortProperties": [
                {
                    "name": "[DocId]",
                    "isDescending": "false"
                }
            ]
        }
    ]
}

Where **LASTID** is 0 on the initial request. Once you get results back, pick the value of indexdocid of the last result, and use that as **LASTID** on the next request. In the below screenshot you would use 2377359 for the seconds request. Continue this logic until you stop getting results, and you should have iterated all files (driveItems) containing the term contoso for the above sample.

MacBook Pro M1 with 4K monitors on a ThinkPad USB-C dock

2023-07-03T15:04:00.000+02:00

I have a couple of 4K monitors at work via a ThinkPad dock. If I were running the native resolution of 3840x2160 pixels the fonts and icons were just too small for my aging eyes. The alternative native resolution was 1980x1080, and then things get too large.

The ideal for me is scaling to 2560x1440. Sure you can do this via the display system settings, but then everything is blurry. But there is a fix.

Install DisplayLink Manager from https://www.synaptics.com/products/displaylink-graphics/downloads/macos
Check the experimental mode for 3008x and 2560x modes support
Then pick scaled text in Display settings, getting you a nativ scaled 2560x1440 which is not blurry in HiDPI mode. See https://support.displaylink.com/knowledgebase/articles/1993915.

New useful managed properties to use in Microsoft Search

2023-04-25T15:39:00.001+02:00

For those working with hub sites in SharePoint you have for a long time used the managed property DepartmentId, later accompanied by RelatedHubSites when hub site hierarchies was enabled.

Now the time has come to have these properties, and some more, added to the public documentation.

Take a peek at https://learn.microsoft.com/en-us/sharepoint/crawled-and-managed-properties-overview which covers these new properties available for online experiences.

The documentation UX is not ideal, so ensure you scroll the table of properties to the right to read the comments per property. Here’s a copy of the table for reference where I moved the comment for visibility.

Note the (*) highlighting that it’s not guaranteed that each item has a value in the property.

Property name	Type	Comment	Multi-valued	Queryable	Searchable	Retrievable	Refinable	Sortable	Mapped crawled properties
DepartmentId	Text	Site ID of the hub of the immediate hub. Applies to all items in the hub/associated sites.	No	Yes	No	Yes	Yes	No	ows_DepartmentId
RelatedHubSites	Text	Site IDs of associated hubs including hub hierarchies. Can be used instead of DepartmentId for most scenarios. Applies to all items in the hub/associated sites.	Yes	Yes	No	Yes	No	No	ows_RelatedHubSites
IsHubSite	Yes/No	Applies to the site result of a hub (contentclass=STS_Site)	No	Yes	No	Yes	No	No	ows_IsHubSite
ModifierAADIDs	Text	Semi-colon separated list of AADIDs for modifiers of a file or page ordered in date descending order. (*)	Yes	Yes	No	Yes	Yes	Yes
ModifierDates	Date and Time	Semi-colon separated list of modification dates for modifiers of a file or page ordered in date descending order. (*)	Yes	No	No	Yes	No	No
ModifierNames	Text	Semi-colon separated list of the names for modifiers of a file or page ordered in date descending order. (*)	Yes	Yes	No	Yes	No	No
ModifierUPNs	Text	Semi-colon separated list of UPNs for modifiers of a file or page ordered in date descending order. (*)	Yes	No	No	Yes	No	No
ChapterTitle	Text	Semi-colon separated list of auto-generated chapters on Teams meeting videos. (*)	Yes	Yes	Yes	Yes	No	No	ChapterTitle
ChapterOffset	Text	Semi-colon separated list of time codes matching the chapter titles for auto-generated chapters on Teams meeting videos. (*)	Yes	No	No	Yes	No	No	ChapterOffset

* Property is not guaranteed to contain data.

Retirement of Dynamic Ordering feature in classic search experiences

2023-04-25T14:57:00.002+02:00

In MC44789 post from April 22nd, 2023, Microsoft announced the retirement of the dynamic ordering feature experience in classic search.

If you don’t know what the feature is, the below image highlights the feature seen in the query builder in classic search result sources, query rules and search web parts.

The above screenshot show a rule which if it matches the term xrank in the title results will be boosted to the top of the result list.

Wait what?? So I will no longer be able to boost items per my own logic? Sure you can, and this is called out in the MC post – “Functional parity may be achieved by adding XRANK clauses directly to the query template in the Query Builder dialog.”

Previously when testing the query from the test tab you could see the output of the final query. However this is no longer the case and I’ll teach you how to transition dynamic rules over to manual XRANK.

Today using the constant boost, or cb, parameter to rank is not the recommended approach. The reason is that the internal rank scale has changed over the years so the value 5,000 may or may not be required to move something to the top. The below example has a rank of –17921 so adding 5000 would not help.

The recommended parameter to use today is to use standard deviation boost with the stdb parameter.

See https://learn.microsoft.com/en-us/graph/search-concept-xrank or https://learn.microsoft.com/en-us/sharepoint/dev/general-development/keyword-query-language-kql-syntax-reference#dynamic-ranking-operator for all parameters.

Manually writing dynamic ordering rules as XRANK

A query temple to boost a result to the top can then look like:

{?{searchTerms} XRANK(stdb=100) Title:xrank}

Feel free to replace 100 with a smaller or larger number as needed.

If you want to boost items with title=foo pretty high, and less with title=bar you can use a nested XRANK statement, similar to what multiple dynamic ordering rules will accomplish.

{?({searchTerms} XRANK(stdb=5) Title:foo) XRANK(stdb=2) Title:bar}

If you want to demote results instead of promoting them, use a negative number.

If you go for decimals instead of integers, I recommend reading https://www.techmikael.com/2014/11/you-should-use-exponential-notation.html to ensure they always work.

Filter on managed properties in search with or without values

2023-04-25T13:20:00.004+02:00

Back in 2014 I wrote the post How To: Search up items which don’t have a value set, which covers how to write keyword query syntax (KQL) filters to return or restrict items depending on if a specific managed property has a value or not. Recently Microsoft added support to more easily query if managed properties of type Text contain or does not contain a value.

Here’s a link to the updated documentation:

https://learn.microsoft.com/en-us/sharepoint/dev/general-development/keyword-query-language-kql-syntax-reference#filter-on-items-where-a-text-property-is-empty-or-contains-a-value

Note: The new supported syntax only works for Microsoft 365 / Online

Items missing or having a text value

The syntax is as follows:

KQL Syntax	Description
NOT <Property Name>:*	Items where a property does not have a value
<Property Name>:*	Items where a property does has a value

The documentation uses the following example to list SharePoint sites associated to a hub site.

(DepartmentId:* OR RelatedHubSites:*) AND contentclass:sts_site NOT IsHubSite:true

Deciphering the query:

KQL	Description
(DepartmentId:* OR RelatedHubSites:*)	return items which has a value in the original DepartmentId managed property or in the successor RelatedHubSites property
contentclass:sts_site	return only site items
NOT IsHubSite:true	exclude hub site results

Note that hubs connected to another hub will not be included in the above query. If you want those, then remove the NOT IsHubSite:true part and post-process the results as needed.

For completeness let’s cover how to accomplish the same for other types of managed properties.

Items missing or having a YesNo value

To find items missing a value in a date property the syntax shown in my 2014 seems to no longer work and should be replaced with the following where the date is some low non-used date.

KQL	Description
NOT (RefinableYesNo00:true OR RefinableYesNo00:false)	return items not having a value in a YesNo property
(RefinableYesNo00:true OR RefinableYesNo00:false)	return items having a value in a YesNo property

Items missing or having a date value

To find items missing a value in a date property the syntax shown in my 2014 seems to no longer work and should be replaced with the following where the date is some low non-used date.

KQL	Description
NOT RefinableDate00>1900-01-01	return items not having a value in a date property
RefinableDate00>1900-01-01	return items having a value in a date property

Items missing or having a number value

For number type managed properties it’s easier as you typically know the range of values.

KQL	Description
NOT Size>=0	if the managed property only contain positive values, then this will return all items with no value set
NOT RefinableDecimal00>=0 NOT RefinableDecimal00<0	return items where the property RefinableDecimal00 has no value
Size>=0	return all items having a value which is greater than your smallest value

There are still new things to learn from the SharePoint Search API I won't share. I will NOT!

2023-04-07T16:22:00.002+02:00

…I will, just a tad bit late :)

This was a tweet I made Friday October 21st once I understood the root cause of an API issue which has popped up in the last months. The issue affected PnP Modern Search web parts when query rules were enabled, and also the Search Query Tool with default settings.

I thought it was a weird API issue which had been introduced as part of an ongoing service upgrade for Microsoft Search lately, but turns out everything was working as expected – except the expected part hasn’t been expected for the past many years. And a big thank you to engineers at Microsoft helping me understand what the root cause is.

On the API side it manifests itself as follows with the following simple API REST query executed in the SharePoint Search Query Tool where you only get 2 main results where you would expect 10.

https://tenant.sharepoint.com/_api/search/query?querytext='mikael'&rowlimit=10

Where are the rest of my 10 results? Well, they happen to be located in the Secondary Results, a place I never looked.

I’ll explain the behavior, and it is actually correct (sort of), and I will explain why this happens now in 2022.

A trip down memory lane

When SharePoint 2013 was released Microsoft released the feature of query rules, which allowed to bring in result blocks into the search results as seen below.

The below screenshot triggers the rule “People Name in SharePoint” which bring in two result blocks.

And the query rule definition

The definition above says to always place people on top, and possible show documents authored by the person as a block within the results, or interleaved.

The thing is that the logic/setting to have it ranked has changed.

Todays logic – changed in October 2021

The old logic

The old logic introduced with SharePoint 2013 would start the block high up, and if results in the block was not clicked it would move down the page, and eventually off the page, which is what has happened for most customers over the years.

The new logic now introduced will ALWAYS interleave the block on the page 1 results, never moving it off the page.

So how does this affect the API?

By default an API query will invoke query rules unless explicitly turned off, e.g. the above query https://tenant.sharepoint.com/_api/search/query?querytext='mikael'&rowlimit=10

As Modern Search was introduced quite some time back this has greatly reducing the use of the classic search center. This means that people haven’t clicked results in result blocks from quite some time, no clicks are recorded and the block moved off the page – never appearing in API queries.

Now as the logic has changed, the blocks come back, which is not a bug, but maybe not expected.

Together with query rules there is another API setting available, one I have never thought about, but it’s been there all along. “Enable Interleaving” which by default is set to true documented at https://learn.microsoft.com/en-us/previous-versions/office/sharepoint-csom/jj262234(v=office.15).

Of course, if you don’t need query rules for your scenario you should always disable them on the API call. Problem solved!

Then again, using the PnP modern search web parts a common scenario is to use promoted results, and thus you need query rules enabled. Which leads to queries on people names triggering the original “People names rules” causing interleaving to happen and the results split into primary and secondary result tables in the response.

The solution then is to set EnableInterleaving=false.

Changing the query to https://contoso.sharepoint.com/_api/search/query?querytext='mikael'&enableinterleaving=false&rowlimit=10 ensure 10 results as expected in the primary result set.

I have released a fix to the Query Tool which by default will disable interleaving, or you can set it yourself.

https://github.com/pnp/PnP-Tools/releases

And I have made the same fix to the PnP Modern Search Web Parts v4.8, and any interleaving should be done manually at the template level if strictly needed.

Query variable trick in Microsoft Search verticals (and classic)

2023-04-07T16:02:00.003+02:00

Microsoft has been working on both classic and modern scenarios for Microsoft Search, and evaluating existing solutions to determine the best way to support query variables. This post is not exclusive to Microsoft Search, and the same technique can be used with any SharePoint classic search experience. The only difference is the type of query variables that are supported for each experience.

For supported query variables in Microsoft Search modern experiences see https://learn.microsoft.com/en-us/microsoftsearch/manage-verticals#profile-query-variables.

For supported query variables in classic search see https://www.techmikael.com/2014/05/s15e03-query-variables-constant-trouble.html.

Solution

The sample case solution provide an option to filter search results down a city. All items are tagged with a managed property City to allow for the filtering. On the SharePoint page of the solution the user can pick their own or a specific city. When picking their own, no query parameter is passed with the city. When picking a specific city the user is sent to a vertical in Microsoft Search passing the city value as a query string parameter:

_/layouts/15/search.aspx/verticalname?City=Helsinki

Which brings us to the query template to use:

{searchTerms} {?City:{Request.City} NOT UNIQUESTRING}{?City:{Profile.positions.detail.company.address.city}}

To see what properties you can use for a Profile query variable, view the output of https://graph.microsoft.com/beta/me/profile in e.g. Graph Explorer. For our test case the City location for a person is available via the query variable {Profile.positions.detail.company.address.city}.

What the above query template achieve is: If a query string parameter City is present, this will be used as part of the query. If not present, the City value of the logged in users profile will be used instead. The {?} notation means that if a query variable is missing, the part enclosed within the braces will be removed all together from the template on evaluation.

I’m using a trick with UNIQUESTRING (which could be any random unique string not present in the search index) to invalidate the last part of the query if we have a query string parameter in the URL. It adds invalid KQL sort of for a property which does not exist, and is thus ignored.

Let’s add some examples to illustrate the evaluation where the ignored part of the query is highlighted in yellow, and the inclusion part in green. The user’s profile value for city is Oslo.

Scenario 1 – Click on Oslo

?City=Oslo
Users City=Oslo

Ending query: City:Oslo NOT UNIQUESTRINGCity:Oslo

Scenario 2 – Click on Helsinki

?City=Helsinki
Users City=Oslo

Ending query: City:Helsinki NOT UNIQUESTRINGCity:Oslo

Scenario 3 – Click on My City

?City=<missing>
Users City=Oslo

Ending query: City:Oslo

Scenario 4 – Click on Helsinki (and missing a city in the profile)

?City=Helsinki
Users City=<missing>

Ending query: City:Helsinki NOT UNIQUESTRING

Scenario 5 – Click on My City and missing a city in the profile

?City=<missing>
Users City=<missing>

Ending query: <empty>

And that’s all there is to it. By matching values on a users profile with values on other data you can create quick navigation and filtering scenarios. By adding SPFx into the mix even more control and logic can be built around the search results pages and passing in values.

Retirement of custom default result sources in Microsoft Search for modern search experiences

2023-03-14T14:58:00.002+01:00

In November 2021 I posted about bookmarks being the successor feature of promoted results for organizational scoped searches in Microsoft Search, which was the first step to modernize the Microsoft Search stack and remove dependencies on classic SharePoint search features and API’s.

The next step is now under way, as announced by MC526131 - Retirement of custom default result sources in Microsoft Search for modern search experiences.

For most customers the change, which will start April 10th 2023, should have no impact. The way KQL rewrite works for a default result source was never intended for modern search experiences as any change was applied to all verticals showing SharePoint and OneDrive content. The ability for an admin to edit and add KQL per vertical in the modern experience is a better and more accurate feature – succeeding the result source feature which doesn’t really work well in modern search experiences in SharePoint. See https://learn.microsoft.com/en-us/microsoftsearch/manage-verticals#keyword-query-language-kql for more information on vertical management.

I want to be crystal clear that nothing happens to classic search experiences nor to experiences which are powered by the SharePoint Search API. Everything keeps on working as before – it’s just Microsoft Search in out-of-the-box modern experiences which retires reading the setup.

I also want to point out that this does not effect query rule triggered promoted results on SharePoint sites or SharePoint hub-sites, as the modern experience will show a promoted result for these scopes regardless of the result source they may have been targeted towards.

And as a last note, this only applies to environment where search vertical administration is rolled out.

That’s it and you can likely ignore this post as it should not affect you

Surface Dynamics 365 Data in Microsoft Search

2022-07-04T13:55:00.002+02:00

If you’re a user of Dynamics 365 did you know that it’s now possible to surface search results from Dynamics 365 in Microsoft Search?

Head over to https://docs.microsoft.com/en-us/microsoftsearch/manage-dynamics365, or direct your admin to follow the directions on how to enable the experience.

Quick steps:

Navigate to https://admin.microsoft.com/Adminportal/Home?#/MicrosoftSearch/connectors
Click “add a new app or service”
Pick D365 and follow the setup wizard

Sensible defaults – avoiding error on first navigation to the Files tab in a Teams channel

2022-01-20T10:38:00.005+01:00

I won’t take credit for the solution myself, as this was shared to me by the awesome Remi Blom-Ohlsen, who is too timid to share great tips with the world himself :)

We’ve all been there, and if you create solutions for customers involving Teams you are bound to have encountered the issue. After the team is created and you immediately navigate to the Files tab in a channel, you get an error message.

Navigate to the Posts tab and back, and all is working.

When creating Teams using out of the box user interfaces you still have to live with this. If you however use a custom ordering and provisioning solution you can via code fix this nuance for your users :)

If you are patient and wait a tiny bit, the folder will be created for you. For those who are impatient and want to ensure everything is the best way possible for end user, they can continue to read.

If your provisioning solution is using C# you can ensure the channel folder is creating using code like this. And the crux here is the FilesFolder property on the channel object.

public static async Task<DriveItem> InitTeamDrive(string GroupId, GraphServiceClient GraphClient = null)
{
	var graphClient = <get your client here>;
	var channels = await graphClient.Teams[GroupId].Channels.Request().GetAsync();

	foreach (var channel in channels)
	{
		if (channel.DisplayName == "General")
		{
			var drive = await graphClient.Teams[GroupId].Channels[channel.Id].FilesFolder.Request().GetAsync();
			return drive;
		}
	}
	return null;
}

The similar direct graph call would be.

GET https://graph.microsoft.com/v1.0/teams/<group id>/channels/<channel id>/filesFolder