
I like to play games at work. Specifically the games on LinkedIn and Wordle. A lot of my colleagues do too.
Scores get compared in little sub-groups, shared across multiple chats, sometimes debated with more energy than the actual project we are supposed to be discussing. (No regrets. About fifteen minutes a day. Worth every second.)
What I started thinking was: what if we had our own version? Same idea. A daily challenge, something quick and low-stakes, but shared inside Teams. People play, scores land on a company leaderboard automatically, no separate app to download, no new login to create, no additional licence to buy.
That last point mattered. Everyone already has an E3 or E5 licence. If the answer required premium Power Platform licences or a third-party service, I wasn’t interested.
So the question was: is it actually doable on what we already have?
(Spoiler. Yes.)
What we already have
An M365 E3 or E5 licence gets you SharePoint, Power Automate with standard connectors, and the ability to deploy SPFx web parts through the App Catalog and pin them as Teams tabs.
That’s the stack. No Azure Functions. No Cosmos DB. No premium connectors.
The plan was straightforward enough on paper. Build the game as an SPFx web part, use SharePoint Lists as the data layer, and handle the backend logic in Power Automate using only standard connectors.
The bit I spent the most time thinking through was submissions. In a game like this, the player knows the answer the moment they have played. If they can write directly to a shared list and read it back, they can see other people’s answers before they play, or adjust their own score after the fact.
That kills the whole thing.
The submission security model

The solution was a custom
AddOnly permission level on the submission queue list. Users can drop a record in. They cannot read anything back. Cannot see their own submission, cannot see anyone else’s, cannot edit after the fact.
There’s a separate locked Submissions list that only the automation touches. The flow picks up from the AddOnly queue, validates the entry against a stored hash, and writes the confirmed record to the locked list. The answer itself is stored as a SHA-256 hash of the answer plus a salt, stripped from the default view so it never surfaces to anyone browsing the list directly.
The leaderboard is a read-only view rebuilt by a scheduled flow each evening. Players can see where they stand. There’s no live score they can game by timing their submission.
(Yes, somebody on the team WILL try to cheat. They always do. Build for that, especially those ofus that are curious about how everything works 🤓)
Three flows
The automation is three flows, all on standard connectors:
- OnNewQueueItem – triggers when a submission lands in the AddOnly queue, validates the answer against the hash, writes the confirmed result to the locked submissions list
- DailyLeaderboardRebuild – runs at 23:58, ranks the day’s submissions and updates the leaderboard
- DailyChallengeActivation – runs at midnight, flips the next scheduled challenge from Scheduled to Active
Challenges are pre-loaded into a DailyChallenges list. Each row has a date, a seed value the web part uses to deterministically pick the word, and the answer hash. The activation flow just flips the status. No answers are ever sent to the frontend.
Provisioning
The whole data layer provisions with a single PowerShell script. It creates the SharePoint site, sets up all six lists with the right columns, indexes, and permission levels, locks down the submissions list, removes the answer hash from default views, and seeds the word list into the Games list. One run, environment is ready for the SPFx app to be deployed and pinned in Teams.
The app registration for app-only auth uses a certificate rather than a client secret, generated by a companion script and uploaded to Entra ID. One-time per tenant.
Does it actually work?
Yes.
The web part loads inside Teams as a tab. The game runs. Submissions go in. The leaderboard updates overnight. Nobody can cheat without access to a SharePoint backend they were never supposed to have.
Total additional licensing cost: zero.

Wordle is the first game type. The architecture was built to support multiple games in the same data model, so adding new ones is a case of extending what is already there rather than starting from scratch.
(LinkedIn-style daily puzzles next, probably. Followed by whatever else gets shouted into the office chat at 9:01 every morning.)