Record Locking Good to Know
- Only Major Objects can be locked.
- When a parent record is locked, its entire form is locked, including any child records in the Arrangement; however, child records can still be changed from another location or through a different process (example: A User can update a related Task, etc.).
- If two Users simultaneously edit the same record (example: Informational lock allows a User to edit the record even if another User is currently editing it, or a non-participating entity, such as an Automation Process, One-Step Action, Scheduler, or mobile client, edits a record while it is locked), the User will be given the option to reload or merge simultaneous edits.
- By default, a
One-Step Action honors the record locking behavior of the record on which it
is used. For example, if Incident is configured to lock records, and a
One-Step Action is run to update the active Incident record (the record is open or
selected in the Grid), the
One-Step Action will attempt to lock the record.
- A One-Step Action will attempt to lock the active record when the specific Action to update a record executes (including Actions that update or create child records).
- One-step Actions running against a group of records (such as a Search Group), honor the record locking configuration only on the active record. For any other records in the group, record locking is bypassed.
- If a One-Step Action Action acquires a lock, the lock is released based on the Business Object's record locking configuration (example: If the Business Object is configured to automatically release locks upon save and the One-Step Action Action saves the record, then the lock is released when the One-Step Action saves the record).
- If a One-Step Action attempts to lock a record that is locked by another User, a warning appears stating that the record is already locked, and One-Step Action execution fails. If record locking is informational, One-Step Action execution only fails if the maximum number of locks is exceeded.
- If the
One-Step Action is run against a group of records, and attempts to lock records that
are already locked by other Users, a warning appears stating which records were
already locked and could not be updated; however, the
One-Step Action will update the remaining records in the group.
Note: A One-Step Action that updates a Business Object can also be configured to explicitly acquire a lock before running to ensure that the active record is locked prior to One-Step Action execution, not just when a specific Action to update a record is being executed. Acquiring a lock prior to One-Step Action execution ensures that the One-Step Action will not fail if a particular Action cannot acquire a lock. If a One-Step Action is configured to acquire a lock prior to execution, it can also be configured to release the lock after the entire One-Step Action finishes executing.
- In the Browser client, automatic record locking notifications are not available, so Renew is not an option. Users are given the option to reload or merge only if they attempt to save changes to an already changed (and saved) locked record (example: Allowed with informational locking and or a non-participating entity).
- The Scheduler, Automation Processes, and Users making use of the CSM Web Service do not participate in record locking, meaning they neither lock a record nor see locks on a record. This means that if one of these entities needs to edit a locked record, it will be able to do so. In the event that simultaneous edits are made to a record, CSM will give Users the option to merge changes.
- By default, the Customer Portal does not participate in record locking, meaning Customers never lock a record or "see" a lock on a record. If the Portal is explicitly configured to participate (in enforced locking), it silently participates, meaning the Customer automatically acquires and releases locks (so that Users are prevented from editing). The only time a Customer receives a locking message is if she attempts to edit a record locked by another User. In this situation, the changed record is automatically reloaded if the Customer attempts to edit the record after the User unlocks the record.