Content Manager

🚧

Looking for the old Content Manager docs?

This document is for the Content Manager that was introduced in the Unity Beamable 3.0 SDK. If you are looking for documentation about the old window in 2.x, here it is, Content Manager (Version 2.x)

This page includes everything needed to use this tool window with the "Beamable SDK for Unity".

The purpose of this Tool Window is to allow front-end administration of player Content by the game maker.

The new Content Manager in Unity now uses the Beamable CLI Content Manager, enabling content management even outside Unity.

While the previous Unity implementation relied on saved on disk ScriptableObjects, this updated version reads and parses the JSON files (the CLI’s format) into memory-only ScriptableObjects. This ensures full compatibility with CLI workflows while preserving all Unity-specific features.

This change unifies content management across Beamable’s ecosystem without disrupting existing Unity workflows.

📘

Related Guides

A common use case for the feature is covered in the guides.

• See Content » Guide for more info

The User Interface

Here is the user interface of the Beamable "Content Manager" tool window.

To open the Content Manager, select it from the Beamable Button.

Advanced

This section contains any advanced configuration options and workflows.

Content Types

See Content - Overview (Content Types) for more info.

Content Status Bar

Status Levels

Auto-Sync

The Content Manager now supports Auto-Sync, which automatically detects remote content changes and downloads them to your local environment. No manual syncing required.

Automatic Updates: Whenever content is modified or created remotely, the changes are seamlessly pulled to your local workspace.

Conflict Handling:
A file is marked as Conflicted only when:

• Both local and remote versions have been modified, and
• The changes are incompatible (i.e., they don’t match).

No conflict is triggered if:

• Both sides made identical changes (e.g., the same field updated to the same value).
• The file is deleted on both sides.
• Only one side has changes (remote-only or local-only modifications sync normally).

This feature streamlines collaboration by keeping content in sync while safeguarding local edits.

Validate

The validation window automatically filters any invalid content and lists it in a list. It centralizes all invalid content and validation error messages into a single place, allowing you to fix them individually without needing to search for them in the Content Editor.

Sync

The Sync operation enables synchronization between local and remote content, reverting any local changes to match the remote data on Realm. You can choose to sync specific content types:

• All Modified: Updates local versions of remotely modified files
• All Conflicted: Resolves conflicts by syncing remote changes
• All Deleted: Removes locally deleted files from remote
• All Newly Created on Local: Uploads new local content to remote
• Revert All: Discards all local changes (Modified, Created, Deleted, and Conflicted

Then, the Revert Contents validation window gets all local changes and splits them into four categories:

• Created
• Deleted
• Modified
• Conflicted

After validating which contents will be reverted, the content manager will start the process of reverting your local data to match the target Realm.

Publish

The publish process compares the local content to the Beamable back-end and shows the publish confirmation window.

The publish confirmation window organizes local changes into three categories:

• Created
• Deleted
• Modified

When executed, the operation:

1. Uploads all changes to the target Realm
2. Updates the content manifest

Once published, development can safely continue within the game maker's Unity Editor and within the Unity Editor of other team-members. Any players connected to that Realm receive the updated content as well.

Publish Restrictions

The operation will be blocked if:

• No detectable changes exist (created/modified/deleted content)
• Any content is marked as Invalid
• Any files remain in a Conflicted state

This ensures only valid, resolved changes are deployed to your game environment.

Refresh

The refresh process has been updated to serve as a system recovery mechanism. Clicking the refresh button will:

1. Restart the CLI Content Manager directly from Unity
2. Clear all caches
3. Repaint the Unity Editor with the latest changes

This functions as both:

• An automatic fail-safe when errors occur during content operations
• A manual recovery option to restart the CLI content management session when needed

Conflict Handling

When a content conflict is detected:

Publishing Blocked

• The system prevents publishing while any files remain in the Conflicted state.
• This ensures conflicting changes are resolved before they affect live content.

Conflict Resolution

• In the Content Inspector Editor, a new "Solve Conflict" button appears for conflicted files.

Users can choose to:

• Keep Local Version (overwrites remote changes, still need to publish)
• Accept Remote Version (overwrites local changes)

If you want to revert all conflicted files at once using the same strategy, you can do the following on your terminal.

Local

beam content resolve --use local

Remote

beam content resolve --use realm

This approach gives teams explicit control over version resolution while maintaining data integrity.

📘

Best Practice

These hints make efficent use of concepts and workflows.

When collaborating on a team of game makers, here are some suggestions for a safe process to try to lower potential content conflicts.

• Carefully review which content items you publish,
• Only commit contents that have properties or tags changes, don't need to keep track of all referenceManifestId updates.

Storage Location of Content Types

While each content object inherits from Unity's ScriptableObject, these objects exist solely in memory for Unity Editor inspection and are not saved to disk.

The actual content data is stored as JSON files in your project's: .beamable/content/<YOUR_PID>/global/ directory

Deployment (On-device)
The development location is not included in the built game project. Instead, when the player loads the game, a fresh copy of all content is retrieved from the Beamable back-end and stored on-device. This allows Beamable to serve dynamic content to the game project. By default, this is a Lazy loading operation. Each of Beamable's Feature prefabs show a loading progress indicator UI automatically.

Content is stored on-device in a within Unity's Application.persistentDataPath.

 Application.persistentDataPath + $"/content/{contentId}.json";

Version Control Advisory

Each content JSON file contains a referenceManifestId representing its last sync state. This identifier is crucial for:

• Detecting content changes
• Identifying potential conflicts
• Maintaining synchronization integrity

Version Control Best Practices

1. Minimize Unnecessary Commits
   • Avoid committing files when only the referenceManifestId has changed
   • These changes can safely be reverted if needed
2. Handling Revert Operations
   Reverting to an older version will trigger conflict detection (due to mismatched referenceManifestId). To resolve while preserving your content changes, run:
   Shell

   beam content resolve --use local
   

   This command keeps your local content modifications and updates the referenceManifestId to match the remote version for each conflicted content.

📘

FAQ

Here are highlights from the Beamable FAQ: See FAQ for more info.

• Content