Skip to content

Task Types

1) Task Type meaning in Soko

In Soko, Task Type is not just a label. It drives multiple systems:
Filtering & grouping in tables and views.
Skill matching: Task Type is linked to user Skills, so the right people can be assign to right task.
Automated scheduling: the scheduler uses Task Type (plus skill type/level and task complexity) to recommend and assign right Artist.
Finance / costing: rates are configured per Task Type (studio rates + workforce rates, hourly/per-frame).
Pipeline/file conventions: templates can incorporate task type (e.g., output naming profiles based on task type).
Treat Task Type as a stable “discipline/category of work” that affects skills, scheduling, and costing, not as a catch-all for every tiny variation.

2) When it’s better to have FEWER task types

Keep the list small when splitting would create noise without improving assignment, scheduling, or cost tracking.

A) Same skill, just different “flavor”

If the same people do it and the rate is the same, don’t create a new task type—use task name, tags or custom attributes.
Good approach:
Task Type: Animation
Task Name: ani_Hero, ani_BG (short abbreviations are encouraged)

B) Variations that are better expressed as attributes/tags

If you mainly want filtering by “Hero/BG”, “2D/3D”, “Simple/Complex”, etc., that’s often better as custom attributes, not new task types (so you don’t explode the type list).

C) You’re early / still stabilizing your workflow

If you’re unsure, start with a minimal set and only split once you see repeated pain in:
mis-assignments (wrong people suggested),
wrong rates,
messy reporting

3) When it’s better to have MORE task types

Add (or split) task types when the difference is operationally meaningful in Soko:

A) Different skills / different people

If two activities are done by different specialists, they should usually be different Task Types so skill matching and scheduling behave correctly.
Example: Rigging vs Animation vs Compositing (different teams, different skills).

B) Different rate cards / costing logic

If the work must be costed differently (hourly/per-frame, or different default rates), use separate task types because rates are set per Task Type.
Example: Roto and Keying might be split if they have clearly different pricing and workforce rates.

C) Different scheduling behavior / capacity planning

If splitting helps you plan capacity (e.g., you want reporting “how much work is in Lighting vs Comp”), separate task types improve scheduler reports and filtering by task type.

D) Different outputs/tooling expectations

When different task types naturally produce different outputs or need different naming/output profiles, splitting can reduce ambiguity and improve automation.

4) A practical decision checklist

Create a new Task Type if you answer “YES” to any of these:
Does it require a different skill group / different people?
Does it need a different default rate (studio or workforce)?
Will it change scheduling outcomes or capacity reporting?
Does it have clearly different deliverables / output conventions?
If “NO” to all: keep the same Task Type, and differentiate via task name + attributes.

5) Best practices for designing your Task Type system

1) Keep Task Types stable across projects

Because Task Types connect to skills, scheduler logic, and finance rates, frequent renaming/splitting creates long-term maintenance cost.

2) Separate “discipline” from “variant”

Task Type = discipline/category (Animation, Rigging, Comp)
Task Name = variant (ani_Hero, ani_BG, comp_FX, comp_Temp)
Attributes/Tags = metadata (“Hero”, “Complexity 4”, “Vendor”, “Shot Priority”)

3) Make sure every Task Type maps to Skills (or you lose automation)

Scheduler error checks include missing skill types/levels, and scheduling relies on skill matching.

4) Align Task Types with Finance from day one

If you want meaningful profitability and payouts by department, you need Task Types that match how you price and pay people.

5) Don’t overload Task Types to replace folder structure

Use Folder Objects (Sequence/Shot/Asset) + filtering across folders for structure; keep task types focused on the work category.

6) Keep the list “small but complete”

A healthy pattern is:
Core craft types (Model, Rig, Anim, CFX, Layout, Lgt, Comp, Roto/Key, FX, Matchmove, Edit, Sound, etc.)

6) Common anti-patterns (what to avoid)

Type explosion: “Animation Hero”, “Animation BG”, “Animation Polish”, “Animation Fix”… → better as task name variants + attributes.
Types that mix discipline and status: e.g., Comp_WIP, Comp_Final → statuses/versions already handle lifecycle.
Types that no one owns: if you create a type but don’t map skills/rates, automation and finance get inconsistent.

Want to print your doc?
This is not the way.
Try clicking the ··· in the right corner or using a keyboard shortcut (
CtrlP
) instead.