Salesforce Report Folder Viewer Can Edit? Test Creator Rights

Executive Summary

A user who holds only Viewer access to a Salesforce report folder can still save and edit reports in that folder when a user-level permission allows it. Salesforce's Help article dated July 3, 2026 carries the title "User with Salesforce Report Folder View Access Can Save and Edit Reports" ^[1] and attributes the behavior to the Edit My Reports profile permission, which gives a user the ability to save a report to a public folder ^[1]. Salesforce defines that permission as the ability to "edit, move, save, and delete reports that you created in shared folders" ^[2]. The behavior is long-standing rather than new in Winter '27: a 2014 community thread describes a Viewer-only folder where a user could still create and save reports ^[3].

Edit My Reports is not the only path to an unexpected edit. Salesforce states that working with reports and dashboards requires user permissions in addition to folder permissions ^[4], and its own Viewer example says a Viewer who also has Create and Customize Reports can rename or delete a report ^[5]. A third-party deep dive from April 2026 says that "without this permission, Viewer access means truly read-only" ^[6], yet a 2022 community answer says Salesforce treats saving into a public folder as working as designed for anyone who can create reports ^[7]. A permission label therefore cannot prove that a folder is read-only. Only a test with named users can.

This report supplies that test: a two-user acceptance matrix covering five operations plus a personal-folder regression check, built for Winter '27 Lightning Experience with Enhanced Folder Sharing confirmed. Salesforce's Help article says removing Edit My Reports removes the ability to save reports to the public folder; what a Viewer who still holds Create and Customize Reports can rename or delete is the open question. The matrix is an unexecuted test design, so run it in a sandbox before relying on any expectation. Permissions accumulate additively from profiles and permission sets ^[8], so removing one assignment cannot prove a grant is gone, and a muting permission set affects only users assigned through its group ^[9].

Two boundaries keep the change safe. Folder access does not widen data visibility, because object read access, field-level security and record sharing still govern what a report returns ^[10]. And an AI assistant connected through the Model Context Protocol (MCP) can inventory grants and propose a smallest-change plan, but Salesforce's hosted MCP servers run every call as the authenticated user ^[11], and the MCP specification calls for a human in the loop who can deny tool invocations ^[12]. An administrator approves each change and performs the readback.

Introduction and Background

The question behind the search query "salesforce report folder viewer can edit" is operational: can this named user alter this report, and can that ability be removed without breaking the user's personal-report workflow? Administrators, RevOps report owners and consulting partners usually meet it after a stakeholder discovers that a shared reporting folder, shared with Viewer access, has acquired a new or modified report. The instinct is to blame the folder. The documentation points elsewhere.

Salesforce describes three folder access levels. Viewer access allows a user to view the reports or dashboards in a folder, Editor access allows viewing and saving ^[13], and Manager access allows viewing, sharing, saving, renaming and deleting ^[13]. Those definitions are only half of the model. The same Help page says the permissions set on the reports and dashboards themselves determine access to the folder contents ^[13]. Folder level and user permission are two separate gates, and the "Viewer can edit" symptom lives in the gap between them.

Scope and method

This report is an explainer with a test design, not a record of test results. Four scoping decisions apply.

• Release and UI: The worked test targets Winter '27 Lightning Experience. Salesforce's administrator countdown lists production upgrades on September 4, October 2 and October 9, 2026 depending on instance ^[14], and Trailhead identifies Winter '27 as release 264 ^[15].
• Enhanced Folder Sharing: The fixture assumes it is confirmed. Salesforce's Help article says organizations created after the Summer '13 release already have it.
• Users: The main fixture uses internal users only. External-user licensing needs its own source-specific testing.
• Data versus definition: Changes to a report's definition are kept separate from access to the CRM records the report displays.

One limitation affects how to read the citations: Salesforce Help articles render in the browser with JavaScript and can be revised, so confirm the wording of any Help quote in your own org's Help before relying on it.

What is already covered elsewhere

The exception is documented. A CloudAnswers article dated April 9, 2026 already explains it, saying the complaint "almost always" traces to Edit My Reports being enabled on the profile ^[6], and a 2022 Salesforce Stack Exchange question about removing report creation in a public folder cites the official Help article in a comment ^[7]. This report does not claim the behavior is uncovered. Its contribution is a reproducible acceptance worksheet: effective-grant evidence per user, a different-creator control, and a personal-authoring regression check.

The Two Gates: Folder Access and User Permissions

Definitions and taxonomy

Salesforce shares reports by sharing the folder, not the individual report. The effective rule for any operation is the intersection of what the folder access level allows and what the user's permissions allow, with named exceptions where a user permission reaches further than folder access. Table 1 below maps each layer to what it controls and to the documented source.

Table 1 shows why a single label cannot settle the question. A user can be a Viewer on the folder and still hold two or three permissions from the middle rows. The Help access chart makes the combination explicit by stating that working with reports and dashboards requires user permissions in addition to folder permissions. Its Save row, which Salesforce lists as an operation, is the one most often at issue.

Defaults and legacy context

Under Enhanced Folder Sharing every user defaults to Viewer on report and dashboard folders ^[2]. That default is why "everyone has Viewer" is the normal starting state and why the unexpected capability looks like a bug. Before enhanced sharing, the model was read-write at folder level: users with read-write permission on a folder could save reports to it ^[2]. Any org still describing "read-only folders" in legacy terms is using vocabulary that does not map directly to Viewer, Editor and Manager.

The Edit My Reports Exception and Its Neighbors

What Salesforce documents

The July 3, 2026 Help article is the starting point for test expectations. Its title describes a user with only View access who can save and edit reports ^[1], and it ties the behavior to the Edit My Reports profile permission. A separate Salesforce profile-permission reference published April 2, 2026 defines the permission as allowing the user to edit, move, save and delete the user's own reports ^[16].

The permission is meant to be paired with authoring rights. Salesforce's Enhanced Folder Sharing considerations article advises granting Edit My Reports to profiles that already have Create and Customize Reports ^[17], and a published reporting book states that Edit My Reports requires Create and Customize Reports as well ^[18]. CloudAnswers lists the same dependency. For an administrator, the dependency has a practical consequence: if a user has Create and Customize Reports but not Edit My Reports, the user still has an authoring permission that other sources say can save into shared folders.

Where sources agree and where they do not

The disagreement matters because it determines the "smallest change". Three claims appear in the sources.

• Claim A, the exception is real. Edit My Reports lets a Viewer edit what the user created ^[6].
• Claim B, removing it makes Viewer truly read-only. CloudAnswers states "Without this permission, Viewer access means truly read-only" ^[6]. A published reporting book supports the narrower point that without Edit My Reports a Viewer cannot overwrite a report stored in the public folder ^[18].
• Claim C, authoring permission alone is enough to save. The same CloudAnswers article says a Viewer with Create and Customize Reports can run reports in the folder and save new reports to it ^[6]. A 2022 Stack Exchange answer goes further and says the only way to prevent a user from saving a report in a public folder is to remove report creation ^[7], calling the behavior working as designed ^[7].

Claims B and C cannot both be absolute. Salesforce's own Viewer page adds a third data point, saying a Viewer with Create and Customize Reports can rename or delete a report, while the access chart lists save as an operation distinct from view. A 2026 vendor blog reports that Create and Customize Reports could let a Viewer rename reports ^[19], without naming Edit My Reports. Salesforce's Help article says removing Edit My Reports removes the ability to save reports to the public folder, but it does not say what a Viewer who still holds Create and Customize Reports can rename, delete or edit. That is the real unknown, and it is why the matrix below marks three assertions as unknown instead of predicting them.

A 2014 thread shows the same ambiguity. A user with Viewer-only sharing could create new reports and save them in the folder ^[3], and when the asker removed Create and Customize Reports, the New Report option and the Save As button disappeared ^[3]. That thread is more than a decade older than Winter '27 and used an older interface, so it is evidence of long-standing behavior, not a prediction of current behavior.

Report-creator semantics

Edit My Reports is scoped to reports the user created. The sources cited here do not document who counts as creator after a clone, Save As or move. A cloned report is a new asset, so the cloning user would be expected to be its creator, but that expectation is an inference. The fixture must record the creator and owner of each synthetic report after each operation, using the Report object, which is read-only through SOQL and exposes folder name and owner fields ^[20].

Dashboards follow a parallel pattern

The dashboard side mirrors reports. The cheat sheet describes the dashboard counterpart of Edit My Reports as editing, moving, saving and deleting dashboards the user created in shared folders ^[2]. Dashboard subscriptions, export and email are outside this page's scope.

Personal folders

The reason many administrators hesitate to remove the permission is the personal workflow. Salesforce states that Enhanced Folder Sharing has no impact on My Personal Custom Reports and My Personal Dashboards ^[17]. The Edit My Reports Help article says removing the permission removes the ability to save reports to the public folder, but "it preserves their ability to create, edit, or clone reports to their Personal Custom Reports folder." The matrix still treats personal-folder authoring as a regression check, so confirm the documented expectation in your org.

Public versus explicitly shared folders

Both folder types use the same access levels, but they differ in how the Viewer default and hidden folders behave. The cheat sheet's description of Manage Reports in Public Folders covers "all folders, including hidden folders" ^[2]. The Unfiled Public Reports folder is a distinct case, so treat it as a separate test target rather than assuming it behaves like a custom shared folder. A vendor knowledge base summarizes the common assignment as giving View, Edit or Manage permission when adding someone to a report folder ^[21].

Tracing Effective Grants

Profile, permission sets and groups are additive

Salesforce describes permission sets as granting more access to users without changing their profile ^[22], and the Salesforce Admin Blog notes that permission sets can only give more access ^[8]. A permission set group includes all permissions of the permission sets it contains ^[23]. The consequence is simple but easy to forget: setting Edit My Reports off on the profile proves nothing if a permission set or group still turns it on.

Muting adds a second subtlety. A group can have up to one muting permission set ^[9], and muting affects only users assigned through that group ^[9]. If the same permission also reaches the user from a profile, a standalone permission set or another group, the user still has it despite the muting permission set ^[9]. After any edit, permission set groups recalculate, and Trailhead lists the valid statuses as Updated, Outdated, Updating and Failed ^[23]. Test only when the group shows Updated.

Three ways to find the grant source

• User Access Summary: Setup's View Summary for a user can show which profile, permission sets or permission set groups are granting the user a permission ^[24]. Confirm the exact label in the org's UI.
• SOQL on assignments: PermissionSetAssignment represents a user's assignment to a permission set or permission set group ^[25]. Salesforce's administrator blog documents the pattern of asking which permission sets give a named user a specific permission ^[26], and notes that each permission set group or profile has an associated permission set ^[26].
• Field-level lookup: The PermissionSet field reference lists PermissionsEditMyReports ^[22], PermissionsManageReportsInPubFolders and the IsOwnedByProfile flag. The field reference used here is the API version 248.0 copy, so confirm the fields in the current API version.

The adaptation of the administrator-blog pattern to a user permission such as PermissionsEditMyReports is an inference, not a documented recipe. Muted permissions inside a group need the group summary view, not a plain field query. A query that finds nothing should be reported as "no grant found by this method", not as "no grant exists".

Folder membership is a separate check

System permissions and folder membership are separate sources. A user can be a Viewer through one share entry and an Editor through another, because Salesforce grants the greatest permission when a user is identified in more than one entity ^[27]. Group membership matters here, since a folder shared to a public group applies to the group's members, which GroupMember records represent. The Folder object holds one content type per folder, and the UI-visible shares must be read from the folder's sharing dialog or the folder sharing REST API, which handles up to 500 recipients per call compared with 25 in the UI ^[27].

Winter '27 considerations for tracing

Two Winter '27 items affect the tracing work. Salesforce is enforcing profile filtering, so users can see only their own profile name unless assigned View All Profiles ^[28], which can break a query that reads other users' profile names. A Winter '27 release update also introduces a dedicated View Setup Audit Trail user permission ^[28]. The Admin Blog's Winter '27 reports section covers record preview and does not mention folders or Edit My Reports ^[28]. That blog is a curated highlights post rather than the full release notes, so treat this as "no change identified" and check the Winter '27 release notes for your org.

Building the Two-User Acceptance Test

Specify the operations before touching access

Define success and intentional denial separately. For a shared reporting folder that must become read-only while personal authoring survives, five operations matter.

• O1, run a shared report: must succeed for every user with folder access.
• O2, edit a report the user created: the intended outcome is the report owner's decision, because this is the operation Edit My Reports exists to allow.
• O3, edit a report another user created: the intended outcome is denial for ordinary users.
• O4, save a new report into the shared folder: the usual intended outcome is denial.
• O5, clone into a personal folder: must succeed, because it is the personal workflow being preserved.

Fixture

Use a sandbox, never production reports. A sandbox is isolated from production, so changes there do not affect it, but a sandbox copy goes stale: customizations and data changes made in production after the copy are not reflected ^[29]. Refresh before the test if the permission configuration changed recently, and note that the sandbox org ID changes on each refresh. Local external client apps are not copied to a new sandbox on clone or refresh, which matters if the rehearsal involves an AI client.

• U1, the creator: a non-admin internal user who creates synthetic report R1 in Folder F while holding whatever access is needed to save there (for example, temporary Editor access that is reverted to Viewer before the test).
• U2, the control: a second non-admin user whose report R2 gives the different-creator control.
• Folder F: a shared folder with both users at Viewer, confirmed in the sharing dialog.
• Constant permissions: keep every other permission identical between scenarios, changing only Edit My Reports.

Record each result in a worksheet row with these fields: user, effective grant sources, report creator, folder access, operation, documented expectation, observed result, test timestamp, change approval and rollback step.

Acceptance matrix

Table 2 is an illustrative before/after grid, not a set of observed results. Every row is a synthetic fixture, the "before" column assumes Edit My Reports is on and the "after" column assumes it is off with Create and Customize Reports retained. "Unknown" marks a case where the sources conflict, and the last column is the personal-folder regression check.

The matrix contains 10 before/after assertions. Six carry a documented or expected outcome (O1 both columns, O2 before, O4 before and O5 both columns) and four are unknown (O2 after, O3 both columns and O4 after, because the after column assumes the Viewer retains Create and Customize Reports). The matrix has not been run, so none of the 10 has an observed result. The point of the grid is the four unknowns. They are the cases where an administrator who removes Edit My Reports and assumes the folder is now read-only is relying on an unverified assumption, and where a result of "still allowed" means another grant source exists or the documentation is narrower than the behavior.

Reading results

• O4 still allowed after removing Edit My Reports: Create and Customize Reports, a broad permission such as Manage Reports in Public Folders, or a second Edit My Reports source is granting it. Return to the tracing step.
• O2 denied but the report owner needs it: this is a trade-off for the report owner. Present it instead of silently granting a broader role.
• O5 fails after the change: the change broke the personal workflow. Roll back and narrow the change.

Changing folder sharing without breaking access

Because a user receives the greatest permission across share entries, downgrading one entry from Editor to Viewer does nothing for a user who is also covered by a second Editor entry through a group or role. List every entry that reaches the user, change the smallest set, and retest. Sharing a report folder requires either Manager access to that folder or the Manage Reports in Public Folders permission ^[30], so the person making the change must hold one of them.

Data Visibility Is a Separate Question

A folder grants access to report definitions, not to the records beneath them. Salesforce's own Viewer description says folder access does not determine access to folder contents. Three layers still apply when a user opens a report.

• Object access: a report returns no records when the user lacks at least Read access to the object.
• Field-level security: a report troubleshooting article tells admins to check field-level security for every field on the report ^[31].
• Record sharing: record-level security gives users access to some object records but not others, and API clients can query or update only the objects and fields the logged-in user's permissions allow ^[32].

Making a folder read-only therefore does not tighten data access, and loosening folder access does not expose records the user cannot already read. Dashboards add one more variable. A dashboard run as a named person shows every viewer data according to that person's access, and the running user determines whose permissions are used to populate the dashboard. Keep dashboard running-user review as a separate task from this folder test.

AI-Assisted Inventory and Change Planning

An AI assistant is useful for the clerical parts of this work: normalizing visible grants and the folder and report inventory into the matrix, attaching the source API names (such as PermissionsEditMyReports), and flagging paths it could not see. It should also propose a smallest-change plan and a negative test. It should not approve its own plan.

What MCP does and does not give

The Model Context Protocol specification says tools are model-controlled, and that there should always be a human in the loop with the ability to deny tool invocations ^[12]. It also says hosts must obtain explicit user consent before invoking any tool ^[33], that clients should log tool usage for audit ^[12], and that tool annotations should be treated as untrusted unless they come from trusted servers ^[12]. Salesforce adds that annotations are hints, not enforcement.

Salesforce's hosted servers

Salesforce's hosted MCP servers reached general availability, with a developer blog dated April 29, 2026 describing them as production-ready for every Enterprise Edition org and above ^[11] and the repository README stating that they are generally available ^[34]. The developer documentation says they are intended only for customers with Flex Credits ^[35], and the sources differ on how to read eligibility, so check your own entitlements. Operationally:

• Disabled by default: MCP servers must be explicitly enabled by an administrator ^[36].
• External Client App: connecting a client uses an External Client App ^[37], and by default any user in the org can authenticate through it ^[37], so limit it by permission set.
• User-bound: every transaction runs as the authenticated user ^[11], and if a user cannot perform an action in the Lightning UI or over the REST API, they cannot perform it through MCP ^[38].
• Data rules apply: field-level security, object permissions and sharing rules apply to every tool call ^[39].
• Start restrictive: Salesforce advises beginning with the most restrictive configuration that meets the use case ^[38].

For this task the useful read-only server is sobject-reads, which can discover schema, query records, search across objects and traverse relationships ^[40], and which Salesforce recommends trying first because it is read-only. Whether the connected user can query PermissionSetAssignment or folder share data depends on that user's permissions, and no official page read during research confirms those objects are exposed, so verify with a trial query. The Metadata Grounding server returns results from the Salesforce Catalog index rather than the live org ^[41], which makes it unsuitable as sole evidence for a permission audit. Write-capable servers deserve more care. For its Headless 360 server, which is in Beta, Salesforce tells administrators to require client-side approval before a tool that changes org configuration runs ^[42] and to make such changes in a sandbox or Developer org before production.

The Salesforce DX server

The Salesforce DX MCP server exposes only tools marked GA by default ^[43] and includes an assign_permission_set tool ^[43]. A GitHub issue states that it reaches end of life on November 2nd, 2026 ^[44], that the npm package will be marked deprecated ^[44], and that Salesforce tooling is now delivered as skills ^[44]. Because the scheduled end-of-life date is November 2, 2026, check the repository for current status and plan new work around the hosted servers or skills.

Where Cirra AI fits

Disclosure: this article is published on Cirra AI's site, and Cirra AI offers a hosted MCP server for administering Salesforce from an AI client. Evaluate it, like Salesforce's own hosted and DX servers, on the criteria used above: acts as the connected user, honors that user's permissions, supports approval before changes, and works in a sandbox first. Verify inventory and change support for report folders and permission sets in a sandbox before depending on any tool, and see Cirra AI's MCP server page for the vendor's own description of its capabilities.

A bounded workflow

• Read: the assistant lists the user's profile, permission sets and groups, with API names, and marks unknown paths.
• Propose: it names the smallest change, such as removing one permission set assignment, and a negative test.
• Approve: an administrator reviews the plan against the matrix and approves.
• Change and read back: the administrator applies the change in the sandbox, and the readback uses a Salesforce-side view. Setup Audit Trail shows only the 20 most recent changes on screen, with a download covering 180 days ^[45], and entity records are deleted after 180 days. It logs permission sets assigned or removed for a user.

Data Analysis and Evidence

Evidence base and date stamps

The sources in this report carry very different ages, and the dates show how long the behavior has been discussed. Table 3 lists the principal evidence items, their dates and what each does and does not establish.

Table 3 shows a split worth stating plainly. Three Salesforce-authored sources define the permission, three practitioner sources interpret it, and the interpretations diverge on one question: what is left of a Viewer's write ability once Edit My Reports is removed. Salesforce's Help article answers part of that question: removing the permission removes the ability to save reports to the public folder. It does not settle what a Viewer who still holds Create and Customize Reports can rename or delete, which is why the matrix leaves four cells unknown.

Quantities that affect the plan

• Share entries per folder action: 25 recipients through the UI against 500 through the folder sharing REST API.
• Audit window: 20 changes on screen and 180 days of history by download.
• Permission set groups: at most one muting permission set per group.
• Matrix size: 10 before/after assertions, 6 with a documented or expected outcome, 4 unknown, none observed (the matrix has not been run).
• Release timing: Winter '27 production upgrades on September 4, October 2 and October 9, 2026 ^[14].

No usage counts, time-saved figures or security scores are offered here because no source supports them.

Implications and Future Directions

For administrators, the main implication is procedural. A request to "make the folder read-only" should become a written test plan before any permission changes, with the intended outcome of each of the five operations agreed with the report owner. The common failure mode is removing a single permission, observing nothing in the UI, and declaring success. The tracing step exists to prevent that, and the muting rules show how a change can look correct and still leave the grant intact ^[9].

For consulting partners, the acceptance matrix can become a standard deliverable. It documents the decision, supports rollback, and separates definition access from data access, which clients often conflate. Because results depend on the specific org's profiles, permission sets and folder shares, the worksheet should be attached to the change request with timestamps and approver.

Several things could change the picture. Salesforce may clarify the Viewer-plus-Create-and-Customize behavior in the Help access chart, and a later release could alter how the sources reconcile, so check the Winter '27 release notes for your org. The scheduled end of life of the Salesforce DX MCP server on November 2, 2026 ^[44] and the growth of hosted servers mean that AI-assisted inventory will increasingly run through hosted servers that act as the connected user. Salesforce also says hosted MCP servers will evolve and change from release to release, so any workflow built on a specific tool should be retested after each release.

Frequently Asked Questions (FAQs)

Can a Salesforce report folder Viewer edit reports?

Yes, under documented conditions. Salesforce's Help article says a user with only View access can save and edit reports because of the Edit My Reports profile permission. The permission is scoped to reports the user created.

What is the difference between Viewer, Editor and Manager?

Viewer allows viewing, Editor adds saving, and Manager adds sharing, renaming and deleting. User permissions still apply on top.

Does Create and Customize Reports let a Viewer save to a shared folder?

Sources disagree. One vendor blog says a Viewer with it can save new reports, and a community answer treats this as working as designed, while the Help article attributes saving to Edit My Reports. Test it in a sandbox.

How can an administrator find out why a user can edit a report they only view?

Check the folder entries for that user, then the effective permissions from the profile, direct permission sets and permission set groups, using the user summary view and an assignment query ^[26]. Confirm no second source grants the permission.

Will removing Edit My Reports break personal reports?

It should not. Salesforce's Help article says removing the permission preserves the ability to create, edit, or clone reports in the Personal Custom Reports folder, and the personal-folder regression row of the matrix confirms that in your org.

Does folder access grant access to the data in the report?

No. The report's results depend on object read access and field-level security.

Conclusion

The question "can a Viewer edit a Salesforce report?" has a documented answer and an undocumented remainder. The documented part is that Edit My Reports lets a user edit, move, save and delete reports they created in shared folders, even where folder access is Viewer. The undocumented remainder is what else, in a given org, still lets a Viewer write: authoring permission, broad folder-management permission, a second grant source, or a folder share the administrator did not know about.

The practical conclusion is a decision rule. Decide the five operations and their intended outcomes first. Trace every grant source for the named users, not just the profile. Reproduce the behavior with two non-admin test users in a sandbox, including the different-creator control and the personal-folder regression. Change the smallest thing, retest both the forbidden shared-folder operation and the preserved personal workflow, and keep data visibility as its own check. Where a necessary shared workflow conflicts with strict isolation, take the trade-off to the report owner. Nothing here is specific to Winter '27, and the long-standing behavior is expected to hold, but only the test can show that it does in your org.