Reporting Snapshot Running User
A Reporting Snapshot Running User is the Salesforce user account whose data access and report permissions decide which records a reporting snapshot captures when it runs.
Definition
A Reporting Snapshot Running User is the Salesforce user account whose data access and report permissions decide which records a reporting snapshot captures when it runs. The snapshot reads the source report as that user would see it, then writes the results into a custom target object on the schedule you set.
The running user is a required setting on every reporting snapshot. It carries weight beyond convenience, because the captured rows bypass normal sharing once they land in the target object. Anyone who can read the target records sees the running user's view of the data, even data they could not otherwise reach.
How the running user shapes a snapshot's results
Where the running user fits in a snapshot
A reporting snapshot has four moving parts: a source report, a custom target object, a set of field mappings, and a schedule. The running user is the fifth and arguably the most consequential. When the scheduler fires, Salesforce runs the source report as the running user, takes the resulting rows, and inserts them as new records in the target object. The running user is not the person who scheduled the snapshot or the person who reads the data later. It is the identity Salesforce assumes for that one report execution. You set the running user on the snapshot definition page, in Setup under Reporting Snapshots. The field uses a lookup, so you pick a specific active user. Because the snapshot runs unattended on a timer, the choice you make once governs every future run until someone edits it. That is different from a report you open by hand, where your own permissions apply each time. Here the result depends entirely on the account you named, not on whoever happens to look at the target records.
Permissions the running user must hold
The running user needs more than a license. Salesforce requires that account to have the Run Reports permission, plus Create on the target object so the snapshot can insert rows. If the target custom object is still In Development rather than Deployed, the running user also needs Customize Application. Miss any of these and the run fails rather than producing partial data. Folder access is the quiet requirement people forget. The source report lives in a report folder, and the running user must be able to open that folder. If the report sits in a private folder owned by someone else, a running user without access cannot read it, and the snapshot errors out. The same applies if the running user is later deactivated. Salesforce reports the failure in the Run History section with a message such as the running user being inactive. Treat these permissions as a checklist when you assign or change the account, since a snapshot that quietly stops running can leave a gap in your historical data that you only notice weeks later.
The security bypass you have to plan for
This is the part that surprises admins. Salesforce Help states plainly that the running user determines the source report's level of access to data, and that this bypasses all security settings. Once rows are written to the target object, every user who can view those target records sees the data the running user could see, even values they would never reach through their own role, sharing rules, or field-level security. That behavior is by design, but it changes how you think about the choice. Pick a running user with wide visibility, like a system account that sees the whole org, and the snapshot captures everything. Anyone with read access to the target object then inherits that wide view. Because of this exposure, Salesforce restricts who can even set a running user other than themselves: only users with the Modify All Data permission can do it. Everyone else is limited to running snapshots as their own account. Before you choose a broad running user, confirm that the audience for the target object should genuinely see that scope of data.
Picking the right account for the question
The running user should match the analytical question, not default to the most powerful login available. If you are trending open cases across the entire support organization, a user who sees all cases is appropriate. If you are capturing one region's pipeline for a regional leader, a running user scoped to that region keeps the historical data aligned with who should read it. Many teams create a dedicated, named service user for snapshots rather than tying them to a real person. A real employee changes roles, goes on leave, or leaves the company, and any of those events can break or silently narrow a snapshot. A service account with a stable role, a clear name like Reporting Snapshot Service, and documented permissions avoids that fragility. It also makes audits easier, since reviewers can see at a glance which identity stands behind the captured data. The tradeoff is that a broad service account widens the security bypass described earlier, so scope it to exactly the visibility the snapshots require and no more.
Limits that interact with the running user
Even a perfectly chosen running user cannot escape the platform limits on snapshots. A single run can add up to 2,000 new records to the target object. If the source report returns more rows than that, the extra rows are dropped and not recorded, so a running user with very broad access can actually hit the ceiling faster than a narrowly scoped one. Keep the source report filtered enough that its row count stays under the cap. Other limits shape the design too. The source report cannot have more than 100 selected columns, and the target object cannot have more than 100 custom fields. Reporting snapshots support tabular and summary report formats, not matrix, and they do not support row-level formula fields. All required fields on the target object must be mapped to source fields, or the run fails. None of these limits change based on the running user, but the running user's data scope determines how close you get to the row cap, which is why scope and limits are worth reviewing together.
Scheduling, time zones, and run history
After you define the snapshot and map fields, you schedule it to run daily, weekly, or monthly. The schedule uses the time zone of whoever sets it, not the running user's personal time zone, which is an easy detail to misread. You choose a preferred start time, and the snapshot runs within an hour of it rather than at the exact minute. For monthly schedules tied to a specific day, the run only happens in months that actually contain that day. The Run History section on the snapshot detail page is where you confirm everything is working. It shows whether each run succeeded and, on failure, notes the cause in the Result column. Common failures trace straight back to the running user: the account went inactive, lost folder access, or no longer holds Run Reports or Create on the target. You can also send completion emails to yourself or to additional internal users, which helps surface a silent failure before the data gap grows. External users cannot be added to that notification list.
Set the running user on a reporting snapshot
The running user is set while you define a reporting snapshot in Setup. You assign it once, and it governs every scheduled run until edited. Choose the account before scheduling, since the snapshot reads the source report as that user.
- Open the Reporting Snapshots page
From Setup, type Reporting Snapshots in the Quick Find box and select Reporting Snapshots. Click New Reporting Snapshot, or open an existing one and click Edit.
- Select the running user
In the Running User field, click the lookup icon and pick an active user whose data visibility matches what the snapshot should capture. Only users with Modify All Data can choose a running user other than themselves.
- Confirm the account's access
Verify the running user has Run Reports, Create on the target object, and access to the folder that holds the source report. Add Customize Application if the target object is still In Development.
- Map fields and schedule
Map each required target field to a source report field, then schedule the snapshot to run daily, weekly, or monthly at a preferred start time in your time zone.
- Monitor the run history
After the first scheduled run, open the snapshot and check the Run History section to confirm it succeeded. Optionally add internal users to the completion email so failures surface quickly.
The user whose access governs the source report when the snapshot runs; their visibility defines the captured rows and bypasses sharing on the target.
A tabular or summary report, in a folder the running user can open, whose results are saved into the target object.
The custom object that receives the snapshot rows; required fields must be mapped and it cannot exceed 100 custom fields.
Daily, weekly, or monthly, with a preferred start time in the scheduler's time zone; the run happens within an hour of that time.
- Captured rows bypass sharing: anyone who can read the target records sees the running user's view, even data they could not otherwise access.
- A deactivated running user makes the snapshot fail; deactivating the account silently breaks future runs.
- The running user must have folder access to the source report, not just the Run Reports permission.
- Each run caps at 2,000 new records; a broad running user can exceed it and lose the extra rows, so filter the source report.
Prefer this walkthrough as its own page? How to Reporting Snapshot Running User in Salesforce, step by step
Trust & references
Cross-checked against the following references.
- Define a Reporting SnapshotSalesforce
- Schedule and Run a Reporting SnapshotSalesforce
Straight from the source - Salesforce's reference material on Reporting Snapshot Running User.
Hands-on resources to go deeper on Reporting Snapshot Running User.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What does the Reporting Snapshot Running User determine when the snapshot executes?
Q2. An admin swaps the Running User on a snapshot from a rep to the VP of Sales. What changes in the next run?
Q3. Which trade-off matters most when picking a Reporting Snapshot Running User?
Discussion
Loading discussion…