Skip to main content
TestPulse requests only the scopes it needs. It never writes on its own: every write is triggered by an explicit gesture on your part, and each one is bounded to what it creates.

​
The two write scopes

​
vso.test_write — Coverage Builder

Powers only the Coverage Builder’s create action. Create-only: it never overwrites or deletes an existing plan or suite.

​
vso.work_write — exploratory testing

Powers only what an exploratory session files at your request: a Bug, a Test Case, the session’s tracking Task, and their attachments. All created, never modified — TestPulse links a new work item to your story, it does not touch the story. One narrow exception: at session closure, an optional dialog can set the state of the Task TestPulse just created, in the same gesture. That is the only post-creation write in the product, and it never applies to anything that existed before.
Adding a write scope to the manifest is an administrator action and triggers an extension re-approval for the organisation. Until then, everything read-only keeps working — only the corresponding create action is unavailable.

​
Permission ≠ scope

A 403 when creating a plan is almost always an area-path ACL — the Manage test plans permission is granted per area path — not a missing scope. See Create the plan in Azure DevOps.

Privacy & data

Where data lives.

Read-only by design

The read/write boundary in detail.