Records Managers can use the Make workspace/folder read-only event in iManage Disposition Manager to prevent further filing and modification of the targeted workspace hierarchy. This helps Records Managers control activity after a workspace has reached a defined stage in its retention lifecycle. The event can be applied to both public and private workspaces and folders.
All activities related to making the workspaces or folders read-only are captured through auditable tasks and timeline entries, providing visibility into ownership and security changes. Closed workspaces can also be reopened when required, restoring the original ownership and permission configuration.
Considerations
The primary purpose of the Make workspace/folder read-only event is to prevent further filing from a defined point in the retention lifecycle of a workspace. Workspace and folder owners may retain the ability to file content through ownership permissions. To fully restrict filing, Records Managers can optionally transfer ownership to a designated user during event configuration.
Although this event prevents further additions and changes to workspaces and folders or subfolders, Records Managers should continue to include record declaration events in their schedules to prevent further changes to existing documents and their versions.
If there's a workspace closure event that precedes the declaration event by some time, any checked-out document may be amended in the interim. iManage Disposition Manager checks for errors in checked-out documents during the declaration event.
Ownership transfer is optional and applies to the targeted workspace, folders, and subfolders, except where containers are governed by a different retention schedule. Document author and operator values aren't modified. When ownership is transferred to the selected user, the previous owner access is added to the Access Control list with read-only access. Any folders that inherit security from this folder have the same change applied.
Records Managers should consider the impact of inherited security and refile behavior when planning to use this event. Workspace security configuration may affect how read-only restrictions are applied and maintained, including scenarios where users gain access through inherited permissions or refile operations.
In this release, the event to make workspaces, folders, or subfolders read-only acts on the workspace it’s applied to, and any child containers that inherit security or have it refiled from that workspace. It doesn't apply to any child folders or sub-folders that don't inherit security or have it refiled from the parent. This is planned for a subsequent release.
When the event to make workspace, folder, or subfolders read-only is triggered and the tasks fail, the status is displayed as Completed with errors and these tasks are displayed on the Errors page. Records Managers can view the timelines of the event and download the timeline in CSV format.
The lifecycle of this event is:
Browse to the Upcoming task.
Execute the Making workspace read-only task.
Reopen the workspace using Revert (if required).
Retry the original make workspace read-only task (if required).
CAUTION: Reopening a workspace or folder isn't an event that can be added to a schedule. To reopen a workspace, go to the previousMake workspace/folder read-only event in Triggered tab and use Revert. This creates a new task.
If a reopened workspace later needs to be closed, Records Managers should return to the previous Making workspaces and folders read-only event and use Retry to close the workspace. This also creates a new task on the Tasks page.
Reverting a workspace closure restores the original permissions and ownership configuration captured when the workspace was closed. Revert activity is separately audited and retained alongside the original closure activity. If the permissions and ownership were manually changed between when the workspace was made read-only and when it was reverted, these changes aren't saved.
Folders or sub-folders with their own security are set to read-only directly. Access for users who have read/write or full-access permissions to the folder is changed to read-only. Users who don't have access to the folder don't gain access to it.
Folders that inherit security from their parent folders or workspace inherit the changes from their parent folders or workspaces.
To make a workspace or folder read-only, when creating events, Records Managers should select the Make workspace/folder read-only option in the Type field. They should select Transfer Workspace/Folder Ownership and select the new owner in the New owner field if they want to transfer the ownership.
When Records Managers run tasks that make all workspaces and folders read-only, the timelines don’t display the Make workspace/folder read-only action if they inherit security from their parents. The Make workspace/folder read-only action is displayed for workspaces and folders if they don’t inherit security because iManage Disposition Managers directly modify the security for these workspaces or folders.