Repository navigation
Retrieving Permission Set with RetainFieldHistory User Permission In Org Doesn't Include Permission #3648
Copy link
Copy link
Closed
Labels
owned by another teamThe Salesforce CLI team does not own this work but will pass on the information to the correct team.The Salesforce CLI team does not own this work but will pass on the information to the correct team.validatedVersion information for this issue has been validatedVersion information for this issue has been validated
Description
Summary
I try to retrieve a permission set from my org.
- In the org, the permission set has RetainFieldHistory enabled
- When I retrieve it, the permission set metadata file doesn't include it.
- CLI command:
sf project retrieve start -m PermissionSet:sysadmin
In contrast, the user permission is included, when I retrieve the standard System Administrator profile
sf project retrieve start -m Profile:Admin
Steps To Reproduce
- Have an org, where Shield's Field Audit Trail is enabled
- Create a custom permission set
- Enable the user permission
RetainFieldHistory - Retrieve it via the CLI by running
sf project retrieve start -m PermissionSet:sysadmin
Tip
use sf doctor --create-issue to automatically fill the required information
Expected result
Expected the permission set to include:
<userPermissions>
<enabled>true</enabled>
<name>RetainFieldHistory</name>
</userPermissions>
Actual result
It didn't include the user permission, despite being set in the org.
Additional information
System Information
Which shell or terminal are you using? PS
{
"architecture": "win32-x64",
"cliVersion": "@salesforce/cli/2.150.6",
"nodeVersion": "node-v24.19.0",
"osVersion": "Windows_NT 10.0.26200",
"rootPath": "C:\\Users\\ext-nto\\AppData\\Local\\sf\\client\\2.150.6-c049970",
"shell": "cmd.exe",
"pluginVersions": [
"@oclif/plugin-autocomplete 3.3.0 (core)",
"@oclif/plugin-commands 4.2.0 (core)",
"@oclif/plugin-help 6.3.0 (core)",
"@oclif/plugin-not-found 3.3.0 (core)",
"@oclif/plugin-plugins 5.5.1 (core)",
"@oclif/plugin-search 1.3.0 (core)",
"@oclif/plugin-update 4.8.0 (core)",
"@oclif/plugin-version 2.3.0 (core)",
"@oclif/plugin-warn-if-update-available 3.2.0 (core)",
"@oclif/plugin-which 3.3.0 (core)",
"@salesforce/cli 2.150.6 (core)",
"agent 2.0.5 (core)",
"apex 4.1.1 (core)",
"api 2.0.9 (core)",
"auth 5.0.6 (core)",
"code-analyzer 5.16.0 (user)",
"data 5.1.7 (core)",
"deploy-retrieve 4.1.2 (core)",
"info 4.0.9 (core)",
"limits 4.0.4 (core)",
"marketplace 2.0.5 (core)",
"org 6.0.11 (core)",
"packaging 3.0.6 (core)",
"schema 4.0.6 (core)",
"settings 3.0.6 (core)",
"sobject 2.0.5 (core)",
"telemetry 4.0.6 (core)",
"templates 57.0.11 (core)",
"trust 4.0.10 (core)",
"user 5.0.2 (core)",
"sfdx-git-delta 6.45.1 (user)"
]
}Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
owned by another teamThe Salesforce CLI team does not own this work but will pass on the information to the correct team.The Salesforce CLI team does not own this work but will pass on the information to the correct team.validatedVersion information for this issue has been validatedVersion information for this issue has been validated
Activity
github-actions commentedon Sep 11, 2026
Thank you for filing this issue. We appreciate your feedback and will review the issue as soon as possible. Remember, however, that GitHub isn't a mechanism for receiving support under any agreement or SLA. If you require immediate assistance, contact Salesforce Customer Support.
soridalac commentedon Sep 15, 2026
Hi @nickytorstensson, thanks for reporting! the cli writes the xml returned by the metadata API as-is, it does not filter or modify userPermissions. This is a platform gap issue rather than a cli. To confirm, could you run both retrieves with
SF_MDAPI_TEMP_DIRset? This saves the raw Metadata API response before any CLI processing:Then compare:
nickytorstensson commentedon Sep 21, 2026
Hi @soridalac
I am unable to run your script, the very first command. Could you help me here?
nickytorstensson commentedon Oct 1, 2026
Hi @soridalac I hope you're doing well. Have you seen my previous comment?
soridalac commentedon Oct 1, 2026
Hi @nickytorstensson , sorry for the delay! The error you're seeing is because ps is setup differently, try this:
Replace with your target org alias. This will help us determine whether the Metadata API itself is omitting
RetainFieldHistoryfrom the PermissionSet response, or if something in the CLI processing is filtering it out.nickytorstensson commentedon Oct 2, 2026
@soridalac I ran all your commands, but the final two rows (4.) does not yield any output.

It looks like when I run (2.) and (3.) then the path still remains in the force-app rather than in the temporary directories you specified.
With this, the results are the same as my initial screenshot. The profile includes the system permission, but the permission set does not.
soridalac commentedon Oct 2, 2026
@nickytorstensson , thanks for trying! Were the temp dir have any files or empty? If the temp dir were empty, which is why step 4 had no output. Try to combine them into one line command:
$env:SF_MDAPI_TEMP_DIR="C:\temp\mdapi-ps"; sf project retrieve start -m "PermissionSet" -o <your-org-alias>$env:SF_MDAPI_TEMP_DIR="C:\temp\mdapi-profile"; sf project retrieve start -m Profile:Admin --target-org <your-org>Then check if the temp dirs have files:
If they do, run the same Select-String from step 4.
SF_MDAPI_TEMP_DIR doc: https://developer.salesforce.com/docs/platform/sfdx-setup/guide/sfdx-setup-trouble-temp-mdapi-dir.html
nickytorstensson commentedon Oct 5, 2026
@soridalac , are you sure the command "Select-String" is doing the right thing?
Now I ensured that the folders have content, but the command still doesn't do anythin:
soridalac commentedon Oct 5, 2026
@nickytorstensson , can you open both file in the metadata folder and search for the string
RetainFieldHistory? The folder contains the raw server response before any CLI processing. If it's in the Profile but not the PermissionSet, that confirms the Metadata API itself isn't including it.nickytorstensson commentedon Oct 6, 2026
Hi @soridalac the issue is exactly the same as initially posted:
github-actions commentedon Oct 6, 2026
We have determined that the issue you reported exists in code owned by another team that uses only the official support channels. To ensure that your issue is addressed, open an official Salesforce customer support ticket with a link to this issue. We encourage anyone experiencing this issue to do the same to increase the priority. We will keep this issue open for the community to collaborate on.
soridalac commentedon Oct 16, 2026
Closing this issue here, since a bug has already been filed against the correct team to track the fix. Feel free to open a new one if there is an issue with the CLI and we'll investigate.