Tracking Game Assets in Notion, Confluence, and Airtable: Where General-Purpose Tools Fall Short

The appeal of general-purpose tools

When a game team needs to track cosmetic assets, the first instinct is to reach for a tool someone already has open. Notion is popular with indie studios. Confluence comes free with Jira, which most studios already use. Airtable attracts teams that want spreadsheet flexibility with database structure. All three can technically hold asset data. The question is what happens at scale — when the catalog grows past 100 items, each with multiple variants, and the team needs filtering, media management, pipeline tracking, and access control.

This article is not a feature-comparison table. It is a look at the specific friction points that emerge when you try to run a real cosmetic asset pipeline in these tools, based on patterns we see repeatedly in game teams.

Notion: flexible until you need structure

Notion's strength is flexibility. You can build a database with any properties, embed images, link pages, and create views. For a small catalog, this works. The friction starts when:

No variant hierarchy

Notion databases are flat. A hoodie with five colorways is either five rows in one database (duplicating the shared mesh, category, and description on every row) or a parent page with five sub-pages (losing the ability to filter and sort variants as a flat list). There is no built-in way to model a parent-child asset–variant relationship where the parent holds shared data and each child holds per-version data.

Workarounds exist — relation properties linking an "Assets" database to a "Variants" database — but you are building a custom schema from scratch. Every filter, every view, and every rollup must be manually configured. When the schema needs to change, every view breaks.

No 3D preview

Notion can embed images and videos, but it cannot render .glb or .gltf files. If your artists need to preview a mesh with a variant's texture applied, they must open a separate tool. The disconnect between the catalog record and the visual preview slows review cycles.

Media is inline, not structured

Images in Notion are embedded in page content, not attached as structured fields with sort order, primary flags, or gallery views. A variant with six reference images is a page with six images pasted in sequence. There is no API-accessible image gallery, no thumbnail field, and no way to programmatically retrieve "the primary image for variant X."

Permissions are page-level

Notion's sharing model operates at the workspace, page, or database level. You cannot give someone edit access to variant records but read-only access to project settings. In a game team where artists edit content, QA reviews it, and producers control taxonomy, this lack of granularity means either over-permissioning or constant access requests.

Confluence: documentation, not data management

Confluence is a documentation tool. Teams use it for game design documents, technical specs, and meeting notes. Some teams also try to use it as an asset tracker, usually with tables on wiki pages.

Tables are not databases

A Confluence table is a formatted block of text, not a queryable data store. You cannot filter a Confluence table by rarity, sort by status, or search across all tables in a space for a specific asset name. Every "query" is a manual scroll or a browser Ctrl+F.

No relational data

Confluence has no concept of relations between records. An asset page cannot programmatically link to its variants with typed relationships. You can add hyperlinks manually, but there is no way to ask "show me all variants of this asset" without building the list by hand.

Version history is page-level

Confluence tracks page edits, but the revision history shows "the page changed" — not "the price of Variant X changed from $15 to $10." For audit purposes, you need field-level change tracking, which Confluence does not provide.

No media management

Like Notion, Confluence can embed images inline. Unlike a purpose-built tool, it has no thumbnail fields, no image galleries with sort order, and no 3D model rendering. Texture files and mesh previews require external tools.

The Jira argument

The strongest case for Confluence is that it comes with Jira. Teams already track production tasks in Jira, so tracking assets in the same ecosystem feels natural. But Jira issues are not asset records. A Jira ticket says "texture the Desert Camo variant" — it does not store the variant's price, rarity, status, thumbnail, and release target in queryable fields. You end up with production tracking in Jira and asset data in Confluence, with no structured link between them.

Airtable: closest but still generic

Airtable is the strongest contender among general-purpose tools. It has typed fields, relations between tables, filtered views, and a usable API. Teams that invest significant setup time can build a functional asset tracker. The friction is in what Airtable does not have out of the box:

Schema setup is entirely manual

Airtable gives you a blank database. Every field, every relation, every view, and every validation rule must be built from scratch. The asset–variant hierarchy, rarity system, pipeline statuses, tag taxonomy, currency fields, and release versioning that PolyDrobe provides on day one require hours of Airtable configuration — and ongoing maintenance when the schema needs to evolve.

No 3D preview

Same limitation as Notion and Confluence. Airtable can store image attachments but cannot render 3D models. Mesh and texture preview requires an external viewer.

No pipeline-aware statuses

Airtable has single-select fields that can function as statuses, but they carry no semantic meaning. The system does not know that "Review" comes after "In Progress" and before "Approved." There is no built-in status flow, no enforcement of valid transitions, and no dashboard showing pipeline throughput.

Pricing scales quickly

Airtable's free tier is limited to 1,000 records and 1 GB of attachments. A catalog with 200 assets and 5 variants each is 1,000 records before you add any supporting tables. The Pro plan starts at $20/seat/month, and every team member who needs to view the data counts as a seat. For a team of 8, that is $160/month for a tool you still need to configure from scratch.

By comparison, PolyDrobe's free tier includes 100 assets with 10 variants each (up to 1,000 variant records), 1 GB of storage, and 3 team members — with Viewer seats free on all plans.

What a purpose-built tool provides

The common thread across Notion, Confluence, and Airtable is that they require you to build the asset management system yourself using generic primitives. A purpose-built tool like PolyDrobe provides the domain-specific structure from day one:

When general-purpose tools are the right choice

To be fair: if your catalog is under 50 items, you have no variants, you do not need 3D preview, and your team is 2-3 people — Notion or Airtable is probably fine. The overhead of a dedicated tool is not justified when the scale does not demand it.

The breakpoint is usually around 100 items with variants, or when a third team member joins and access control becomes a concern. At that point, the time spent building and maintaining a custom schema in a generic tool exceeds the time it takes to set up a project in PolyDrobe and import your data.

Key takeaways

• Notion, Confluence, and Airtable are capable tools, but none of them provide asset–variant hierarchy, 3D preview, pipeline statuses, or field-level audit trails out of the box.
• Building a game asset tracker in a generic tool requires significant upfront schema work and ongoing maintenance.
• Confluence is particularly poor for asset data — its tables are not queryable, and it has no relational data model.
• Airtable comes closest but requires manual setup and scales to expensive per-seat pricing quickly.
• A purpose-built tool like PolyDrobe provides the domain-specific structure, media management, and team roles from day one.
• The free tier supports enough assets and variants to evaluate whether the structured approach fits your team.