Creative Task Flow
& Productivity Report

The request

• One record per task, aggregated by team and by task type: count and completion time
• Waiting time before a task reaches Creative, in working days
• A manager view of load vs. capacity per team
• The period is chosen by the user, and teams are dynamic, not hard-coded
• Capacity per the request's method: FTE × hours/day × days/week

Constraints we kept

• AJ360 | Ingest is read-only: no fields, no automations, no writes
• Engagement is not loaded: we only chose which fields appear in the sync views
• Every calculation is a formula or rollup, not a script
• Automations reference field IDs, never names
• Working days are set per team by the Creative manager
• Every number is checked against an independent API calculation before sign-off

VIEW 1 Tasks - Creative Base

• Filter: Created ≥ 1/6/2025
• 16 source fields: Task ID, Eng. Task Type, Task Status, Video/Design Status, Video/Design Producer, Created, Publish Date…
• 5,934 tasks today

VIEW 2 History - Creative Base

• Filter: Action Time ≥ 1/6/2025
• Status is one of 2. Cr. In Progress · 2. Cr. ReWork · 3. Review Output · 4. Ready to Schedule
• 23,460 events · fields: Task Status, Task ID, Collaborator, Action Time, Action

Why this design

• Synced fields are read-only and their type can't change, so every calculation lives in a local field on top of the synced table.
• Sync linked tables = OFF: no extra tables pulled in; links are built locally.
• No field was added to Engagement's tables. We only chose what each view exposes.

Operating rule

Both views must keep the same start date. If they drift apart, events lose their task or tasks lose their events, and both drop out of the report.

PROBLEM

The Task ID in the event history changes when the task type changes, so matching on the full text failed for 227 events. Pasting links by hand also stops at a row limit.

SOLUTION

• A TSK field = REGEX_EXTRACT({Task ID}, "TSK[0-9]+"), a stable key that never changes
• Automation RQ2690 | Link Event to Task finds the task by TSK and links the event
• Runs automatically on every new event that arrives through sync

Actual Delivery logic

A delivery doesn't count if the task went back to Creative after it. Ready to Schedule was added because 112 published tasks skipped Review Output and would have been misread as rework.

Order of checks

• No Actual Start → No Start
• No Actual Delivery → Cancelled / Back to Brief / Rework / In Progress
• Task type without standard hours → No Standard
• Otherwise → OK

Technical lesson

A formula shown as a single-select silently falls back to the default option when its text doesn't exactly match an option name. We caught this on 149 tasks and fixed it.

Example: requested Thursday, reached Creative Sunday

How the formula works

• Wait Span (Days): calendar days in Qatar time
• Start Weekday: weekday of the creation date (0 = Sunday)
• For each of the 7 weekdays: if it's a team working day, count how often it falls inside the span
• Changing a team's working days in Local Teams recalculates all its tasks instantly

Checked on 1,306 tasks against an independent calculation: 0 mismatches.

LOAD Load = Std Hours

Standard hours come from the task type, and count only for the tracks the task actually needs.

CAPACITY Capacity

Current team setup

The team lead isn't counted in capacity, because Members Count only counts members. This can be revisited with the Creative manager.

What the checks caught

The first AI-generated (Omni) version of the dashboard read 5 wrong fields: publish date instead of delivery, wait instead of cycle time, capacity instead of review rounds… and showed 1,439% utilization.

We rewrote the element by hand with fixed field IDs, and made it show a clear error if it can't read a field, instead of silently showing wrong numbers.

Documented

Each of the 36 fields we created carries a description of what it computes, its source and who uses it, prefixed RQ2690 |.

State these with every report

• Actual Start = when the task was handed to Creative, not when work began
• Cycle time is calendar hours, not effort; the system records no working hours
• No separate timing for video vs. design: 97–98% of "4. Delivered" values are set by an automation at Review Output
• Producer data is reliable from May 2026
• The median is the right measure: 51 tasks took over 720 hours

Recommendations to measure better

• Add a "Started" status set by the executor when work actually begins, separating queue time from work time
• Require Video/Design Status when sending to Creative (121 tasks arrived with no track)
• Register every producer in Local Teams (only two teams today)
• Track each line separately if management needs video vs. design comparisons

BUSINESS For Creative management

• Assign unattributed producers to their teams: mahmoud shams, Ali Arslan, Baran Yildiz, Muhammed Ali, Mustafa Taha… (68% of the period's load has no team)
• Clarify App Artwork's work: no tasks were recorded for them in the period
• Read the rework rate (49.8%) as a quality signal, not a calculation error
• Decide whether team leads count toward capacity

TECH Technical

• Publish the 3. Dashboard page after review
• One-decimal precision on Wait / Cycle / Std Hours
• Delete 4 unused test fields (flagged in their descriptions)
• Keep both sync views on the same start date
• Revoke the temporary tokens used for verification