I can use my canvas app, but I don't know if it will work for everyone else
The maker can open and use the app with their own account, but cannot confidently say whether each intended user type can open it, see the right information, complete the important task for their role and produce the right saved result. Without a short role-based user test, the first colleagues who receive the app become the test team.
Blocker
Reviewed by Helen Jones
Reviewed by Helen JonesContext
The blocker, in a nutshell
If this blocker is unfamiliar, start here.
This Problem is about user testing. That means giving the published app to a small number of representative users, asking each person to complete a real task without coaching, and checking that the app and its data behaved as expected. An LMS is one example: a learner completes an item, a manager reviews the result, and an administrator checks the saved record. The same method works for request, approval, onboarding, asset and incident apps.
Key Terms
Industry jargon explained
Click any term to see its definition.
The Reality
A day in their life
Non-developer business professional building or owning an internal canvas app
I start the morning with an app that looks finished. I open it as myself, add a test record and see the success message. For the LMS I am building, the learner screen, manager screen and admin screen all seem to be there.
By lunchtime I am about to share it more widely, but I realise I have only ever used the maker account. I do not know whether a learner can see only their own courses, whether a manager can review the right people, or whether the completion record is actually saved where the administrator expects it.
The small win is that one colleague completes the learner journey without help. The uncomfortable part is that their ordinary account exposes a permission problem I never saw. I can fix it, but I still need to check the other roles and rerun the failed task.
What I want is a short, calm way to choose the people and tasks that matter, watch them try the app, check the saved results and decide whether a small pilot is sensible. I do not want to become a software tester or fill in a huge audit pack.
The People
Who experiences this blocker
Non-developer business professional building or owning an internal canvas app
25-50 • Early intermediate maker
Skills
Power Apps screens/forms
SharePoint lists
Basic Power Automate flows
Understands the business workflow
Frustrations
- The app works for me but I do not know whether it will work for everyone else
- Different people need different screens and permissions
- I do not know what to ask a test user to do
Goals
- Know that each important user role can complete its task
- Find permission and workflow problems before a wider rollout
- Make a calm pilot decision without becoming a QA specialist
Pilot user or process owner
Depends on the app working in normal situations and reports issues when the pilot exposes gaps.
Also affected by this blocker. Often shares the same frustrations or creates additional pressure.
Top Objections
- I am not a software tester
- The app is small
- I do not have several test accounts
- I do not want to complete a giant workbook
How They Talk
Use These Words
Power Appscanvas appuserroletestsharepublishrecordpermissionpilot
Avoid
test harnessrelease boundarysource-of-truth read-backversion attributionenterprise UATCI/CDregression framework
Learning Pathway
Canvas App User Testing
Check that each important type of user can complete their real job before a wider pilot.
Showing 2 of 2 recommendations
Course
Start Here
Course Built
◆◆◆◆◆Excellent Fit
Check Your Canvas App with Real Users Before You Share It
From “it works when I use it” to a plain-English record of what representative users attempted, what happened, what was saved, what was fixed and whether a small pilot is justified.
5 lessons90 minbeginner
You'll build: Complete one plain-English User Test Sheet for a published canvas app, showing the two to four roles tested, each role’s task and expected result, what actually happened, what was saved, which important failures were fixed and retested, and the final small-pilot or not-yet decision.
Includes: Progressive plain-English User Test Sheet completed across the five lessons · LMS worked example that can be replaced with the learner’s own roles and tasks
User roles and real tasksPublished app accessHarmless data+4 more
Course
Course Built
◆◆◆◆◇Good Fit
Test Your Power App Before You Share It
From repeatedly clicking through a familiar app to owning a documented pre-share routine that records inspected risks, manual observations, Monitor findings and one automated browser path.
7 lessonsintermediate
You'll build: Assemble a self-contained pre-share-hour.md page containing the prompts, checks and robot-builder instructions needed to repeat the tested routine on another app, plus a short statement of what the completed checks do and do not establish.
Includes: Exported app risk map · One-page test plan · Focused human-test checklist · Monitor evidence notes · Playwright browser check · Reusable pre-share-hour.md routine
Canvas app source exportAI-assisted risk mappingPlain-English test planning+5 more
Root Cause
Finding where this blocker actually starts
We traced backward through five layers of "why" until we hit the source. Here's what's really driving this.
1
Why can the maker use the app while another user cannot?
The maker tests with the account that built the app, so their access and familiar route can hide problems another user will meet.
2
Why do different users get different results?
Different roles may have different app, table, record, connection or flow permissions, and they may be shown different screens or records.
3
Why are those differences not caught before sharing?
The maker has not written down the small number of real tasks each role must be able to complete.
4
Why is clicking through the app not enough?
Without an expected result and a check of the saved data, a success message or apparently correct screen can be mistaken for a successful task.
5
Why does confidence stay low after a fix?
Without a simple defect and retest step, the maker changes the app but does not rerun the failed user task before the next person tries it.
Root Cause
The app is being checked through the maker's account and knowledge rather than through the real tasks, ordinary access and saved results of each intended user role.
The Numbers
How this stacks up
Key metrics that determine the opportunity value.
Overall Impact Score
89/100
Urgency
8.7/10
They need this fixed now
Build Difficulty
8.5/10
Complex, needs deep expertise
Market Size
7.8/10
Healthy demand exists
Competition Gap
8.8/10
Major gap in the market
"I was recently asked to create a strategy to test the power apps. Starting with Canvas apps."
Recent direct practitioner request for a workable canvas-app testing strategy; the original case is a complex app and also discusses automation. — Reddit r/PowerApps, 2026-04-30
More Evidence
What others are saying
"Does anyone have a straightforward way to simulate another user when testing an app?"
Older contextual practitioner evidence of the difficulty of checking role-based behaviour. — Reddit r/PowerApps, 2025-04-11
"when I share the canvas app with other users, they can see the app, but they don't have the permissions to add/edit data."
Older contextual example showing that opening a shared app and being able to complete the data task are separate. — Power Platform Community, 2023-02-15
The Landscape
What solutions exist today?
Current market solutions and where there are opportunities.
M
Maker preview and informal clicking
Approach: The maker opens the app and follows the route they already know.
Weakness: It uses the maker's access and familiarity, so it does not show what an ordinary user experiences.
A
Ask a colleague to have a play
Approach: A colleague explores the app without a written task or expected result.
Weakness: It does not show which important role journeys were covered or whether the saved result was correct.
Leader
P
Power Apps Test Studio
Approach: Low-code end-to-end UI tests for canvas apps.
Weakness: Useful for repeatable checks, but optional for this beginner user-testing job and not a replacement for representative users.
Leader
L
Live monitor
Approach: Diagnoses runtime events, errors and data operations, including user-specific problems.
Weakness: Useful after a failure appears, but it is a diagnostic aid rather than the main user-testing method.
The Gap
Why existing solutions keep failing
The pattern they all miss — and how to beat it.
Common Failure Mode
Testing guidance and diagnostic tools exist, but a non-developer still needs a short role-based routine that starts with real user jobs, uses ordinary user access, checks the saved result and ends with a small pilot decision.
How to Beat Them
Teach one short role-based user-testing routine with an editable test sheet and an LMS worked example, then show the learner how to substitute the roles and tasks from any internal canvas app.
The Fix
What a solution needs to succeed
The non-negotiables and nice-to-haves for any product or service tackling this blocker.
The 3 Wishes
Sit beside the maker and help them check that each important type of user can complete a real task before a wider pilot.
Must Have
Plain-English user-testing scope
Two to four important roles
One real task and expected result per role
Ordinary-user testing of the published app
A saved-result check
A simple problem, fix and retest record
A small pilot or no-pilot decision
Nice to Have
LMS worked example
Optional Live monitor troubleshooting after a failure
One-page editable user test sheet
Out of Scope
Unit tests
Load or performance testing
Automated regression as a prerequisite
Security, compliance or accessibility certification
Enterprise ALM
A bug-free guarantee
Success Metrics
Every important role has a real task and expected result
Representative users test with ordinary access
Important saves are checked
Important failures are fixed or block the pilot
Failed tasks are retested
The decision is no wider than the people and tasks tested
Solution Strategy
Which approach fits you?
A checklist alone can be skimmed without changing behaviour. A short guided Course is justified because the learner must choose representative roles, write real tasks, arrange ordinary-user access, observe without coaching, check saved results and retest fixes.
What we recommend
Make UY3sS8j9TYqMPVzH9B928 the recommended guided route after it is simplified around user roles, real tasks, observed results and a bounded pilot decision.
The Future
What might make this blocker obsolete
Technologies and trends that could disrupt this space. Factor these into your timing.
medium probability
12 months
Power Apps testing and monitoring tooling keeps improving
Course and build-spec should track Test Studio, Test Engine, Monitor, and observability guidance as Microsoft updates the platform.
SaaS: Medium risk
Course: Medium risk
Consulting: Low risk
Content: Medium risk
For Creators
Content Ideas
Marketing hooks, SEO keywords, and buying triggers to help you create content around this blocker.
Buying Triggers
Events that make people search for solutions
- Pilot user reports broken screens
- Flow errors appear after launch
- Manager asks for launch confidence
Content Angles
Attention-grabbing hooks for your content
- Your first users should not be your test plan
- The Power Apps launch checklist for citizen builders
- How to prove a Power App is ready for pilot
- Build a simple feedback loop before the app goes live
Search Keywords
What people type when looking for solutions
Power Apps testingPower Apps Test StudioPower Apps launch checklistPower Apps pilot feedbackPower Apps defect tracking
The Evidence
Where this came from
Every claim in this report is backed by public sources. Verify anything.
7 sources referenced
Source note
Blocker published by Collab365 Spaces, reviewed by Helen Jones on . Cite as "I can use my canvas app, but I don't know if it will work for everyone else", Collab365 Spaces. 7 sources referenced.
Have a question or correction?
No comments yet