Records Managers can use the Make workspace/folder read-only event iManage Disposition Manager to prevent further filing and modification of content within 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 this event is to prevent further filing and modification of content from a defined point in a workspace's retention lifecycle. 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 subfolder, 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, then any checked-out document may be amended in the interim. iManage Disposition Manager checks for checked-out documents erroring out 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.

• 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 workspace, folder, or sub-folders read-only acts on the workspace they're applied to, and any child containers that inherit security or have it refiled from that workspace. They won't apply to any child folders or subfolders that don't inherit security or have it refiled from the parent. This will be updated in a subsequent release.

• When the event to make workspace, folder, or sub-folders read-only is triggered and the tasks fails, the status is displayed as Completed with errors and these tasks will be 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:

  1. Upcoming task

  2. Making workspace read-only task executes

  3. Workspace is reopened using Revert (if required)

  4. Original making workspace read-only task is retried if the workspace needs to be closed again.

• 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.

To make a workspace or folder read-only, Records Managers when creating events should select Make workspace/folder read-only option in the Type field. Select Transfer Workspace/Folder Ownership to transfer the ownership. When this field is selected, select the new owner in the New owner field.