Reference Glossary
Check-in / check-out
Check-in/check-out is a locking mechanism that lets one user reserve an asset for editing, blocking others from saving conflicting changes until it is checked back in.
Why it matters in a DAM
When multiple people can edit the same source file, simultaneous changes overwrite each other and someone's work silently disappears. Checking a file out signals to the rest of the team that it is actively being worked on, and checking it back in returns it to the shared pool with the new version recorded — basic concurrency control that matters most in DAMs used by distributed creative teams editing shared source files like logos, templates, or layered documents.
A worked example
Common mistake
Users check an asset out to make a small edit and forget to check it back in, leaving the file locked for the rest of the team — often for days — until an administrator has to step in and force-unlock it.
Check-in/check-out solves a narrower problem than full version control: it is not about preserving history, it is about preventing two people from editing the same file at the same time and one of them losing their changes when the other saves. It matters most for source files that are edited directly rather than replaced wholesale — layered design files, templates, or master documents multiple contributors touch over time.
The failure mode is almost always the same: someone checks a file out, gets pulled onto something else, and forgets to check it back in. The rest of the team then either can’t edit the file at all or has to work around the lock, and eventually an administrator has to force an unlock — which reintroduces exactly the risk the lock was meant to prevent, since the original user may still have unsaved local changes they think are safe.
Because of that failure mode, teams that rely on check-in/check-out heavily tend to pair it with automatic lock expiration or reminder notifications after a set period, rather than leaving a lock open indefinitely once it is set.
Frequently asked
What specific problem does check-in/check-out solve that plain version control doesn't?
Version control tracks versions after they're saved, then requires merging conflicting ones — it doesn't stop two people editing the same file at once. Check-in/check-out solves that upstream: checking an asset out places an exclusive lock, so everyone else gets read-only access until it's checked back in. This prevents a conflicting save from happening at all, rather than reconciling it afterward, which matters for files like InDesign or Illustrator documents where merging two edited versions isn't possible.
What's the most common failure mode of check-in/check-out systems?
Someone checks a file out, gets pulled onto something else, and forgets to check it back in, leaving the file locked for the rest of the team, sometimes for days.
What happens when an administrator has to force-unlock a forgotten check-out?
If a user checks an asset out and forgets to check it back in — often because they've moved on to another task — the file stays locked for the rest of the team until an administrator steps in. The admin force-unlocks it, typically with a notification to the original owner, restoring access for everyone else. This carries risk: the user may still hold unsaved local changes they believed the lock protected, so a forced unlock can reintroduce the same conflict check-in/check-out was meant to prevent.
What kinds of assets benefit most from check-in/check-out?
The mechanism benefits source files edited directly over time rather than replaced wholesale — layered design files such as InDesign, Illustrator, or Photoshop documents, along with templates and master documents that multiple contributors touch repeatedly. These formats can't be automatically merged the way plain text can, so if two people edit the same layered file in parallel, one person's changes are simply overwritten. Simpler, replaceable assets, like a single photo or a rendered PDF, need the protection far less.
What do teams typically pair with check-in/check-out to reduce the forgotten-lock problem?
Because forgotten check-outs are the main weakness of this system — a locked file can block the rest of the team for an extended period — teams typically pair check-in/check-out with automatic lock expiration, which releases the asset after a set period of inactivity, and reminder notifications that prompt the user to check the file back in before that timeout hits. Together, these reduce how often an administrator has to step in and force-unlock a forgotten asset manually.
What does the rest of the team see while an asset is checked out?
While an asset is checked out, everyone else on the team sees a "checked out by [user]" status displayed directly on the asset, identifying who holds the lock. They keep read-only access, so they can still view, download, or reference the file, but the system either blocks them from saving edits or warns them that a save will conflict with the checked-out version. That status clears once the asset is checked back in and the lock releases.