> For the complete documentation index, see [llms.txt](https://docs.flosum.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.flosum.com/release-notes/backup-and-archive/monthly-releases/backup-and-archive-v4.7.16-monthly-release-notes.md).
# Backup & Archive (v4.7.16) - Monthly Release Notes
{% hint style="info" %}
#### Release Details - Backup & Archive - v4.7.16 - August 04, 2026
This article is intended for Salesforce administrators, compliance officers, and IT teams responsible for managing Salesforce backups and data governance.
**Release Type**
* Monthly
* Applies to Flosum-hosted and self-hosted
**Prerequisites**
* A registered and configured Flosum Cloud Apps tenant
* Appropriate Flosum user permissions (SystemAdministrator or equivalent)
{% endhint %}
##  Summary
This article documents the monthly release for **Backup & Archive (v4.7.16)**.
This release gives administrators finer control over restore and archive operations. Trigger deactivation now supports configurable Apex test levels, and Restore Requests can target individual records instead of every record for an object. Restore reliability also improves through automatic handling of Restricted Picklist fields.
Monitoring and transparency are strengthened as well. A new daily monitoring process alerts customers when no successful backup jobs were completed the previous day, and Search Jobs now display the filters configured for each object.
###  Configurable Test Execution for Automation Processes
#### What Changed
The Automation Processes Trigger deactivation during Archive and Restore operations now supports configurable Apex test execution. When disabling Apex Triggers, you can choose the Salesforce deployment test level instead of always relying on the default behavior.
The supported options are:
* **Run Specified Tests**: execute only selected test classes.
* **Run Local Tests**: execute all local tests in the organization.
The selected test level is saved as part of the Automation Process configuration and is applied automatically whenever trigger activation or deactivation is performed.
#### Why It Was Done
Previously, trigger deactivation always used Salesforce's default deployment behavior, which executes all local tests when Apex metadata is deployed in Production. For organizations with failing tests or large test suites, this could significantly delay restore operations or prevent trigger deactivation entirely.
Allowing you to control the test execution level makes the deployment process more flexible and better suited to different Salesforce environments.
#### What You Will Notice
When configuring an Automation Process that includes trigger activation or deactivation, you will see a new **Test Level** option. You can choose whether to run all local tests or execute only specified test classes.
The selected option is saved with the Automation Process configuration and is used automatically during future trigger deployment operations, helping reduce deployment time and avoid unnecessary test execution where appropriate.
###  Backup Monitoring Email Notifications
#### What Changed
A new automated monitoring process detects organizations that did not complete any successful backup jobs during the previous calendar day. When this situation is detected, System Administrator accounts and any email addresses listed in that organization's notification settings will automatically receive an email alert.
#### Why It Was Done
Successful backups are essential to ensuring your data remains protected. This enhancement helps you identify backup interruptions early, allowing you to investigate and resolve issues before they affect your ability to recover data.
#### What You Will Notice
You will receive an email when no backup jobs are completed successfully during the previous calendar day. The notification provides an early warning that backup activity may require attention, helping administrators take corrective action as soon as possible.
###  Record-Level Selection for Restore Requests
#### What Changed
Restore Requests now support restoring specific records instead of requiring all records for a selected object to be restored.
You can choose to restore either:
* all records for the selected object, or
* only specific records, by searching for and selecting the records you want to restore.
Multiple records can be selected, and you can also restore all records returned by a restore request.
#### Why It Was Done
Previously, Restore Requests restored every record for a selected object, even when only a small subset needed to be recovered. This enhancement provides greater flexibility and helps reduce the amount of unnecessary data restored, making recovery operations more efficient and targeted.
#### What You Will Notice
When creating a Restore Request, you can now choose between restoring all records and restoring only selected records.
If **Selected Records** is chosen, you can search for records, select one or more matching records, or select all records returned by the search before starting the restore. This allows you to restore only the data you need.
###  View Configured Filters in Search Jobs
#### What Changed
Search Job results now display the filters configured for each object directly in the object details. The filters appear along with the object's other details, so the search criteria are visible in the same place as the results they produced. No additional configuration is required to see them.
#### Why It Was Done
Previously, the filters applied to objects could not be viewed after a Search Job was created. Once a job was submitted, there was no way to confirm which criteria had been used, so administrators had to rely on their own records to verify its scope.
This enhancement improves transparency by allowing you to see which filters were used during the search. It also makes results easier to interpret, because an unexpected record count can be checked against the filters that produced it.
#### What You Will Notice
When selecting an object in Search Job results, you can now view the configured search filters by clicking the **See filters** button.
The filters are shown as they were defined when the Search Job was created. This gives you a reliable reference point when you review results.
###  Improved Restore Support for Restricted Picklists
#### What Changed
The Restore process now automatically handles **Restricted Picklist** fields during data restoration.
Before the restore begins, applicable Restricted Picklists are temporarily made unrestricted to allow records containing legacy or inactive picklist values to be restored successfully. Once the restore finishes, the original Restricted setting is automatically reinstated.
#### Why It Was Done
In some Salesforce organizations, records may contain picklist values that are no longer available in the current metadata configuration. Previously, these records could fail to restore because Restricted Picklists prevented invalid values from being inserted.
This enhancement improves restore reliability while preserving the original metadata configuration.
#### What You Will Notice
Restore operations involving Restricted Picklists are now more likely to complete successfully, even when historical records contain picklist values that no longer exist.
The process is fully automatic; no user action is required, and the original Restricted Picklist configuration is reinstated after the restore completes, regardless of whether the restore succeeds or fails.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.flosum.com/release-notes/backup-and-archive/monthly-releases/backup-and-archive-v4.7.16-monthly-release-notes.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
