Outcome and scope
Build a register that connects creative assets with approved versions, permitted uses and actual publication locations. A file folder alone cannot explain which image may be used for which client or channel. The register does not interpret a license by itself; it points reviewers back to the permission record that supports a publication decision.
An asset ID survives filename and output-format changes. Keep each approved derivative version connected to its source, permission evidence and reviewer.
Prepare the fields and destination
Prepare these fields: Asset ID, source reference, creator, permission evidence, allowed use, expiry, approved version ID and publication location. Keep source values separate from a reviewer’s confirmed values, and do not reuse an existing column for a different meaning. Create the first record with practice identifiers in a destination whose read and edit access matches the intended staff roles. Inspect the saved result from that role before using live information.
A thumbnail visible in a register does not mean the original file or contract evidence should be broadly accessible. Review the storage and sharing behavior of attachments before using them for restricted material.
Build the workflow in order
Separate assets from publication locations and link them so one can trace every use. Distinguish source, edited and approved versions. Keep permissions for creative files and contract evidence appropriate to each audience. Assign an owner for broken external references instead of assuming a shared link will remain available indefinitely.
Use structured review fields for channel, client, expiry and unresolved questions alongside the supporting document. Record who checked the evidence and when. Unknown permission must remain a review state. If a crop or retouch becomes a distinct delivery version, preserve its relationship to the original asset.
Before release, reconcile the approved version with the intended use and record its destination. If a permission or expiry changes, filter the affected publications. Preserve historical uses after replacing an image, then inspect the live destination to establish that the replacement actually took effect.
Work through a small example
Use PHOTO-12 in an article body and a listing card, recording two publication uses. Replace only the body version and confirm the register still exposes the card using the older version. Change the permission expiry and check that both locations appear in the review queue.
| State | Check | Action |
|---|---|---|
| Asset intake | Source and permission evidence | Assign assetID and reviewer |
| Use approved | Version matches permitted use | Record the exact publication use |
| Image replacement | Body changed; card still old | Review the remaining old version |
| Use restricted | Permission or expiry changes | Find every affected publication |
Handle changes during operation
Record the usage position as well as the page URL. Replacing a listing card and replacing a body image are different tasks, and completion requires checking the published destination.
Estimate cost and usage
For an asset library, consider attachment volume and access roles as well as record count. Decide whether the register stores originals or references to controlled storage, with lightweight previews where appropriate. Review outside contributor permissions. A cheaper public bucket is not an acceptable substitute for storage that satisfies the permission and confidentiality requirements.
Investigate failures
If the displayed image disagrees with the register, inspect version identifiers, delivery URLs and caching. Deleting a source asset may not remove copies already published elsewhere. For a removal request, track the register change and verification of each publication location as separate completion steps.
Review before release
Before release, test a normal record, one missing a required value, a repeated identifier and an edited record. Use asset id to trace the saved result back to the source. The acceptance condition is: Connect approved asset versions to all uses so a restriction change can be acted on. Record the expected result before testing, compare it with the actual saved state, and resolve unexplained differences before increasing the scope.
Official sources
Pricing, availability and feature limits can change. Check the linked official pages before subscribing.
- Airtable: Linked recordsInformation checked: 2026-10-30
- Airtable: Getting started with form viewsInformation checked: 2026-10-30
- Airtable pricingInformation checked: 2026-10-30
- Airtable pricingInformation checked: 2026-10-28
- Airtable plans overviewInformation checked: 2026-10-28
- Airtable billable collaboratorsInformation checked: 2026-10-28
