Dousen Documentation

Updated July 2026

Dousen connects Jira, Perforce, and your DCCs — Blender, Maya, Houdini, 3ds Max, Substance Painter, Substance Designer, and Unreal Engine — into one unified workflow. A changelist knows which Jira ticket it belongs to, an asset name is checked against your project's rules the moment it's exported, and publishing from one tool hands work straight to the next one — so artists spend their time on art, not on the handoffs between tools.

The three planes

Every Dousen deployment is one to three of these, depending on whether the studio is on the cloud or self-hosted. Everything between them is plain HTTP/JSON — no proprietary protocol to firewall around.

Port reference

Cloud vs. self-hosted

The components

Key concepts

Tasks

Dousen stores no tasks of its own. Jira is the single source of truth. DousenDesktop fetches issues directly using each artist's own Jira credentials and renders them as HTML, so you see the same tasks you would in Jira.

Changelists

Every Perforce changelist opened through Dousen is keyed to a Jira issue key — for example DOU-142. That link is what keeps your work in Perforce tied to the task it belongs to, and it's what lets a changelist submit automatically transition the Jira issue if an admin has configured it.

The bridge

When an artist publishes from one DCC, the local relay fans the event out to the other apps on that machine. Unreal Engine picks the event up and auto-reimports the changed asset — no manual export-and-import shuffle. The same channel carries the active Jira task/changelist to every running DCC, and lets studio tools join in exactly like the built-in addons.

Naming conventions

Asset naming rules are defined per project — as YAML, or as Lua for computed rules — stored in DousenCore, and compiled to a single JSON document every client caches for 5 minutes. Names are assembled structurally from prefixes, suffixes, and dimensions, not from a single text template, so a name assembled in Blender matches what Unreal expects.

Validation

The same document that defines naming also carries validators — automatic checks that run in the DCC before an asset is exported. Errors block the export; warnings are advisory. Admins choose which rules run and at what severity; artists just see the results.

Licensing & accounts

Every studio instance runs against an Ed25519-signed license that it verifies offline, with a 14-day grace period past expiry so a renewal is never a fire drill. Seats are enforced per plan, and every account plugs into one of three sign-in modes — local password, an external LDAP/AD directory, or cloud SSO — with a single active device per account.

Roles

A studio instance checks access as effectively admin vs. non-admin: the roles are admin, producer, and artist, but only admin unlocks the portal's write endpoints (conventions, validators, settings, users). Cloud studios additionally have owner/admin/member roles on the control-plane org — an org owner or admin becomes an instance Admin when they sign into their studio; everyone else becomes an Artist. Full breakdown: User & auth management.

Full documentation map

Every page in the sidebar, grouped the same way and in the same order. If you already know what you're looking for, this is the fastest way to jump there.

Getting started

User guide

Admin guide

Reference

Start here, by role

The docs are organized by what you're trying to do, not by which sub-app owns the feature. Pick your role:

Whatever you're doing, if something doesn't behave the way these pages say it should, Troubleshooting is symptom-first and usually faster than re-reading a guide end to end.

Where to next