Playbook-Based Projects: The New Way to Run Client Work

We've rebuilt how projects work in DesignTech AI. The old "project types" system has been replaced by playbook-based project configuration — a change that makes projects more flexible, more powerful, and much easier to customize for your organization's specific workflows.

What Changed

Previously, project types were a separate configuration entity. You'd create a project type, define its questions and workflow, and then create projects against that type.

Now, any playbook can be exposed as a project type. The playbook defines everything: what questions are asked at intake, how the brief is structured, what automation runs when the project is created. No separate "project type" configuration is needed.

Why This Is Better

One place to configure everything. Your playbooks already define your workflows. By exposing them as project types, you eliminate a duplicate layer of configuration and keep all your workflow logic in one place.

Richer intake. Playbooks support structured questions with validation, conditional logic, and reference uploads. Project intake questions now support everything a playbook step supports — including rich text briefs with entity references to existing content, campaigns, and assets.

Direct execution. When a project is created, the associated playbook executes immediately against the submitted brief. No manual trigger needed. The brief becomes the playbook's input, and execution starts automatically.

AI brief evaluation. Before execution starts, the AI evaluates whether the brief has enough information to proceed. If required fields are missing or the brief is ambiguous, the system flags it for the operations team rather than running an execution that will produce poor output.

How Projects Work Now

1. Intake — Client or team member submits a project brief through the project creation flow or via email intake
2. Evaluation — AI assesses brief completeness and flags any gaps
3. Execution — The associated playbook runs against the brief automatically
4. Monitoring — The project page tracks playbook execution status, generated assets, and communication thread
5. Delivery — Completed assets are surfaced in the project for review and delivery

The project becomes a unified record: brief, conversation, execution history, and deliverables in one place.

Migrating Existing Project Types

If your organization was using the old project type configuration:

1. Open the Workflows page and find the playbook that matches each of your old project types
2. Enable "Expose as project type" in the playbook settings
3. Configure the project intake questions (these replace the old project type questions)
4. Set the project title format and any notification preferences
5. Disable the old project type once the playbook-based version is tested

Projects created under the old system are not affected. They'll continue to show in your project list and their execution history is preserved.

Company Codes and Project IDs

Each project now gets a sequential ID based on your organization's company code — a 3-letter prefix configured in organization settings, followed by an auto-incrementing number. So projects appear as ACM-001, ACM-002, and so on.

This makes project references unambiguous in email threads, client calls, and project management tools. The company code can be configured by a super admin.

What Stays the Same

• Projects still have status lifecycles: Pending → In-Progress → Ready for Review → Complete
• Approval workflows and campaign generation from projects are unchanged
• The project list, project detail view, and email threading are unchanged
• All existing projects and their data are preserved

The change is in how you configure and create new project types. Existing operations continue to work exactly as before.