MintyGo / Production / System 02 of 02
2023Recorded work
Client templates and production-ready task handoffs
Use the client’s usual work structure when available. Otherwise, a standard setup retains writing, editing and delivery steps and carries over the client’s requirements.
- Noah’s contribution
- Explicitly created the fallback task template and described client-field transfer, subtask assignment and the ready-status handoff.
- Historical stage
- Configured template branches and narrated task-field/assignment checks.
- Part of the business
- MintyGo overview ↗
- ClickUp
- Client custom fields
- Task templates
- Writing / editing / delivery subtasks
Inside this system
The workflow
The handoffs
inside the work.
Follow the main path and its branches. Select a step for context; the account below explains what was built, tested or planned.
- Paced article payload
The webhook receives the row information and any client-template match from batch intake. - Reusable client record
Client fields supply website, description, source and the default assignee. - Was a matching template found?
Client-name matching selects a client template; a missing match takes the generic route. - Create from the client template
Use the located template to preserve the client-specific task structure. - Create from the generic template
Preserve a parent task plus writing, editing and delivery subtasks when no client template exists. - Copy client custom fields
On the fallback path, copy reusable client requirements onto the new article record. - Prepared article record
Attach spreadsheet information to the task created by either template route. - Assign the production subtasks
After Ready is set, list the production subtasks and apply the client record’s default owner. - Ready-status handoff
Set the queue status to Ready so the separate article-generation process can begin.
Key records
The information
that carries forward.
| Record | Information | Purpose |
|---|---|---|
| Client record | Reusable client custom fields, including company website, company description and source, plus a default assignee. | Supply the requirements and ownership that an individual spreadsheet row does not contain. |
| Article task | Article-specific spreadsheet information, client context and queue status. | Create the parent work record that can proceed to the next production stage. |
| Production subtasks | Writing, editing and delivery tasks with assigned ownership. | Keep the human production handoffs visible even without a bespoke client template. |
Inside the system / 01
A missing template should not remove the production structure
The workflow first looked for a ClickUp template containing the client’s name. The recorded instructions called for matching capitalization. When a template was found, it supplied the structure for the new article task, and information from the spreadsheet columns was added to that task.
Noah anticipated that someone submitting a batch might not know how to create or update a client template. He therefore created a generic fallback with a parent task and writing, editing and delivery subtasks. The fallback addressed a specific operating problem: a missing template could change how requirements were supplied without eliminating the team’s production handoffs.
Inside the system / 02
Keep client requirements attached to the article
On the fallback path, the integration retrieved the client record and copied its custom-field data onto the article record. Examples mentioned in the walkthrough included the company website, company description and source. The spreadsheet supplied the article-specific information, while the client record supplied reusable context.
The workflow listed the writing, editing and delivery subtasks and assigned the client’s default person to all of them. This version used one common owner rather than separate default writers, editors and delivery staff.
Inside the system / 03
Release a prepared task to the next system
Changing the queue status to ready handed the new task to a separate article-generation system. This was a boundary between preparing work and producing its content. A task could now contain the article request, client requirements and production structure needed for the next stage.
The narrated two-record test located a client template and described populated task fields and subtask assignees. The fallback branch was explained as part of the configured workflow, rather than shown as its own separate end-to-end test. The tasks were still generating at the end, so neither completed articles nor their editorial quality were inspected.
Within MintyGo