Support

Codeit allows for teams of users to collaborate on coding projects.  For example, a supervisor might want to access a task to make client codeframe changes while coders are actively coding.  Other times, it is necessary for multiple people to work on the same task at the same time so that coding can be completed quickly.  This often means that multiple people are accessing and updating the following items simultaneously.

When a user enters a task via the Start Coding Dialog, by default all records for the selected task and wave will be exclusively "locked" by ,or "checked out" to, that user for the duration of their session.  This behaviour is intentional and designed to prevent multiple people from coding the exact same workloads at the same time.  If two people are working on the same items at the same time it may be confusing and error prone as well as being an inefficient duplication of effort.

The table below summarises how Codeit handles concurrent access in each of the following scenarios;

Scenario	Description
Coding	Codeit allows multiple users to work on the same task at the same time, and this is common. Usually this is necessary for reasons of speed - for example, a large project might require multiple coders to work on it simultaneously in order to complete the work before a certain deadline.  Codeit offers various options to manage concurrent coding scenarios like this.   Filters: use a more selective criteria to limit the number of workloads in scope for a session Paged/Percentage Selection: Request a subset of workloads, rather than locking all items Locked workloads: Include workloads even if they are locked to another user Sequential coding: Work through workloads sequentially, issuing small batches of records to sessions on demand (10 sessions are checked out at a time) - This allows very large numbers of coders to work on longer verbatims concurrently, without specifying and locking a fixed set of workloads upfront.
Codeframe editing	Two or more people may use and alter a codeframe at the same time in a variety of scenarios. For example, a codeframe may be shared between projects or tasks or projects and therefore might be active for several people at once. Similarly, two or more people may be coding the same task at the same time. It is also possible for a codeframe to be altered in the Admin section or even via the Codeit API. In any event, Codeit handles simultaneous updates of this nature seamlessly and with minimal disruption to users. When using a codeframe, it is extremely important that you are working with the latest version of that codeframe. For example, it is NO use applying a code to a set of verbatims if another user has removed that code from the codeframe five minutes earlier. Codeit puts various safeguards in place to ensure all users are using the latest version of the codeframe at all times. By default, when a codeframe is changed, users will immediately see a pop-up dialog to notify them that the codeframe has been changed. Optionally, users can be notified whenever a codeframe changes, so they are always aware of when a Codeframe has changed. In order to continue coding (if the user is in a coding screen) they user must click "Reload Codeframe", to continue coding. If required, the change notification dialog can be suppressed. This can be useful when a codeframe is undergoing multiple changes and the notifications become distracting.  To disable notifications (user specific), deselect the option "Display Warning when the Codeframe is externally updated" in the "Settings" ribbon menu. Under normal circumstances, while users are making small changes to a codeframe, it is fine for multiple changes to happen at once.  However, there are some situations where a user might want to hold an exclusive lock on a codeframe for an extended period of time.  For example, when doing a final "clean up" (moving items, collapsing items, tidying labels, creating nets, renumbering etc...) of the codeframe might require an exclusive lock on the codeframe. In this situation, the codeframe can be put into "Edit Mode" by clicking the "Edit Mode" toggle at the top of the codeframe to prevent other users from making changes. Note that if a user remains dormany in 'edit mode', Codeit will automatically end the session, but if it remains on, it can be forcibly switched off via the Administration section, selecting the relevant codeframe and clicking 'unlock'.
Locked workloads	In Codeit, there is a mechanism termed sessions. When a coder opens a coding mode (Block coding, sequential or Verify) the associated verbatims are checked out and locked. No one else can work on the same verbatims at the same time. This is done to prevent coders overwriting each other's work. Sometimes, it is helpful to view locked workloads to reference how other coders have been coding a particular task. Typically these are not included, but you can alter this as per below. By default, these locked workloads are read-only, but you may adjust this.  Note: The "Locked Workloads" and "Locked workloads are editable" options are not displayed by default. In order to enable this for a company (or sub-company) you must switch on via the company settings.
Ending coding sessions	Usually, sessions are closing automatically when a coder leaves a coding mode. Verbatims are then available to be checked out by someone else.  Sometimes, a verbatim may be locked in a session without reason, so as an administrator, you can monitor, or even end, a dead session. From the admin dashboard, select "Active Sessions" and end the session.