Thinkwise Software Factory Create Control Procedures

Creating Control Procedures in the Thinkwise Software Factory

Reference for the full control-procedure lifecycle: control procedure → template → program object item → program object (generated stored procedure/trigger/function/view/etc., deployed to the database, executed by the GUI or Indicium). Apply this whenever an MCP connector with Software Factory access (sf_mcp, indicium) is used to create, assign, or inspect control procedures — follow the connector's standard discovery→act flow; never guess entity/task/property names.

Relevant entity sets: control_proc, control_proc_template, code_grp, prog_object, prog_object_code, prog_object_item, prog_object_item_parmtr, generate_object_code, branch_rdbms_type, and — for the Task code type specifically — task, tab_task, task_parmtr (see "Creating a brand-new Task" below). Relevant tasks — two distinct ones, not interchangeable (see "Actually generating code" below): task_generate_code_grp (bound to control_proc and to the Assigning screen's static_assignment_overview) creates missing prog_object placeholders but does not itself produce code; task_add_job_to_generate_object_code (bound to prog_object_code/ prog_object_overview) is what actually queues a generation job and writes prog_object_generated_code. Domain keys observed in this environment: manage_model/data_modeling (meta-model entities) and manage_functionality (Functionality screen tasks) — try these directly first (e.g. a get_entity_definition/search_domain_capabilities call against the expected domain); only fall back to search_capabilities/get_available_domains on an entity_set_not_found/domain_not_found-style rejection, rather than re-discovering the domain pre-emptively every time.

Before writing anything: confirm the plan

This skill's confirm-before-mutate obligation (see thinkwise_software_factory_mcp_base's "Shared conventions") has a concrete shape here: before the first stage_resource call touching control_proc (or any related entity), state the plan in plain language and get the user's explicit confirmation. At minimum, name:

• Logic concept — which row of the "Choosing the right logic concept" table below (Default, Layout, Context, Process, Trigger/Event, Task, Badge, Change detection, Handler, Subroutine, …), and why that one.
• Code group — the specific code_grp_id that concept maps to.
• Target object(s) — the table/column/task/view this will be assigned to.
• Static vs. SQL strategy — which one, and why (see "Static vs. SQL-typed control procedures" below for the trade-off to lay out).

Only stage the control_proc row once the user has confirmed this plan — don't treat naming a code group or picking an assignment type as a mechanical detail to decide silently on the way to step 3 of "Creating and assigning a control procedure" below.

Check branch_rdbms_type first — before writing a single line of SQL

Do this before writing any template, every time, no exceptions. Query which platform(s) the model actually targets:

execute_odata_query → /branch_rdbms_type?$filter=model_id eq '<model>' and branch_id eq '<branch>' → one row per enabled platform: rdbms_type (byte enum: 0 SQL Server, 1 DB2 iSeries, 3 Oracle, 4 PostgreSQL) + rdbms_name.

Why this has to come first, not "whenever it seems relevant": verified live — a model enabled for PostgreSQL only (branch_rdbms_type returns a single rdbms_type = 4 row) was handed a control procedure template written from habit in T-SQL (getdate(), dateadd/datediff, select top n). Every stage_resource/patch_resource/commit_resource call along the way reported success — there is no dialect validation at write time. The mistake only surfaced by explicitly reading the generated prog_object_generated_code text afterward and noticing it wasn't valid PostgreSQL. Treat "it committed" and "it generated" as proof of nothing about dialect correctness; only reading the actual generated SQL (or checking branch_rdbms_type up front so the mistake can't happen) does that.

Single row returned → single-dialect model

Write the one template in that platform's dialect — before writing any SQL, read references/sql_dialects.md for the dialect/helper-function tables covering all four platforms. rdbms_type is auto-filled consistently across col, dom, prog_object, prog_object_code, and template_prog_object_item — no special handling needed beyond writing the right dialect in the first place.

More than one row returned → the shape of the work changes, not just the SQL text

1. One dialect-specific control_proc_template per platform. control_proc_template's key (model_id, branch_id, control_proc_id, template_id) does not carry rdbms_type — give each platform's version of the logic its own template_id (e.g. <name>_mssql / <name>_pg, or reuse one control_proc_id with distinct template_ids per platform). Never write one template whose literal text merely happens to parse on two engines through escaping tricks — that's this exact bug waiting to resurface the moment one engine's syntax drifts from the other's.
2. One template_prog_object_item row per (rdbms_type, prog_object_id). This junction's key already includes rdbms_type, so wire each platform's prog_object_id (the same logical object, e.g. view_<tab_id>, but a distinct row per rdbms_type) to its matching dialect-specific template_id from step 1. One assignment cannot serve two platforms.
3. Generate and verify for every enabled rdbms_type separately — both halves of "Actually generating code" below (task_generate_code_grp then task_add_job_to_generate_object_code) are addressed per rdbms_type. A prog_object existing, or generation succeeding, for one platform says nothing about the others. Before considering the work done: query /prog_object?$filter=model_id eq '<model>' and branch_id eq '<branch>' and tab_id eq '<tab>' &$select=rdbms_type,generated_code_stale and confirm a row exists with generated_code_stale = false for every rdbms_type branch_rdbms_type returned — then read prog_object_generated_code for each and eyeball that it's actually in the right dialect (right date functions, right paging syntax, right identifier quoting), not just that it generated without an error.
4. Assignment can't be made "generic" to save a step. Once there's more than one dialect, a Static assignment or a template_prog_object_item row is inherently platform-specific — resist assigning the same template to every platform's prog_object_id just because the ids/rows look interchangeable.

See "rdbms_type — when it's actually required" further below for the same key's role specifically in SQL-assigned/dynamic model procedures — this section is the general version, and applies to every control procedure, static or dynamic, the moment real SQL is involved.

Static vs. SQL-typed control procedures

Every control procedure has an assignment field: Static (assign_type = 0) or SQL (assign_type = 2).

• Static — pick program objects by hand, fill in [PARMTR] values per assignment row on the Assigning tab. Simple, explicit, but every new table/task needs a manual assignment. Use for one-off, non-repeating logic.
• SQL (dynamic) — a query in the control procedure decides which objects get the template and what each [PARMTR] resolves to, including duplicating a row per parameter value. Assignments follow automatically as the model changes. Use the moment the same template needs to apply to many objects, or needs to track model changes over time. Reserved in framework code for built-in procedures, but perfectly valid for custom logic once a pattern repeats.

Switching direction later is mechanical, not a merge: static→dynamic converts existing rows into control-procedure code; dynamic→static materializes the query's current result as static rows. If it's not obvious which to start with, ask the user rather than picking one — lay out the trade-off (Static: explicit, one manual assignment per object, easy to reason about, more upkeep as objects multiply; SQL: automatic fan-out that tracks model changes, but the assignment logic itself becomes something to write and maintain) and let them choose, per "Ask, don't default" in thinkwise_software_factory_mcp_base's "Shared conventions."

Generation strategies (SQL-typed only)

The control_proc.strategy enum: delete (0), fully_managed (1), managed_via_staging_table (2). Docs/blog inconsistently call fully_managed both "Fully managed" and "Fully controlled" — same thing.

control_proc_type — separating custom logic from generated infrastructure

A separate field from assign_type above: control_proc.control_proc_type (Byte enum) marks what kind of control procedure this row is, not how it's assigned. Confirmed live values: program_object (0), program_object_item (1), meta_definition (2).

• program_object_item (1) is hand-written logic for one specific object — this is the actual custom business logic a developer wrote (e.g. "default this one column to now").
• program_object (0) and meta_definition (2) are shared generators and framework infrastructure — meta-programming control procedures that produce boilerplate for many objects at once (including the framework's own smoke-test/upgrade/unit-test-scaffolding machinery), or the wrapper templates (_start/_end) that bookend generated code. They aren't application logic themselves even though many generated prog_object rows point at them.

When scoping "what custom logic exists to review/test/document," filter control_proc by control_proc_type eq 1 directly rather than enumerating generated prog_object rows for a code type — scanning generated objects first (e.g. "every table with a Default enabled") overcounts wildly, since dozens of tables can share one generic generator while only a couple actually have program_object_item overrides. This complements, rather than replaces, the "misleading control_proc_id" reading in "Actually generating code" below — that section is for confirming which control procedure produced an already-generated code section by reading its header comments; filtering on control_proc_type is the faster first pass for finding candidates before you get there.

Setting assign_type/control_proc_type when creating a control_proc row: pass the enum's raw numeric code (e.g. 0, 1), not its display label (static, program_object_item) — a label string is rejected with an invalid-value error even though the same field defaults correctly to its numeric form when left unset. If a combined add reports these fields as not-applied, a follow-up edit setting them by numeric code resolves it.

Choosing the right logic concept — before picking a code group

For the full per-concept good-uses/avoid/best-practices, the Handler-vs-Trigger distinction, the "choosing where a rule belongs" decision sequence, performance/security guidance, common failure patterns, and a testing checklist by concept, read references/logic_concept_design_guide.md before writing the actual business logic — the rest of this file covers how to wire whatever concept you land on through the API, not which one to pick or what it should contain.

Code groups (the 24 "code types")

Pull the live list from the code_grp entity set — don't assume which of the 24 groups exist or what they're called. This is the authoritative source; anything hardcoded here can drift stale.

Two broad families exist:

• Business-logic groups fire per-record/session and expose runtime @-prefixed variables (see next section).
• Structural/generator groups emit schema DDL or platform wrappers — just SQL text with [PARMTR] substitution, no business-logic variables.

A small illustrative subset — non-exhaustive, and possibly stale; confirm against code_grp before relying on any of these names:

A script in UPGRADE/MANUAL runs as raw SQL directly against the tables — it does not go through those tables' Handlers. Handlers are separate generated stored procedures invoked by the application/API layer on insert/update/delete, not database triggers, so a seed/migration script inserting or updating rows bypasses them entirely, with no error or warning. Any derived/computed state a Handler would normally maintain for those rows (a cascading rollup, a computed status, an audit stamp) has to be replicated explicitly inside the seed/migration script itself if the seeded data depends on it — don't assume seeding a table's base columns is enough just because a Handler exists on it.

Two separate enablement gates exist — a table-level one and a column-level one — and NEITHER is auto-enabled by assigning a template. Verified wrong in an earlier version of this doc: assigning a template to default_absence/default_lead via template_prog_object_item and re-running generate_code_grp did not turn on the table's Default concept — tab.use_defaults stayed false even though the prog_object rows already existed and the assignment showed up correctly in prog_object_item. The work looked complete (structural wiring verified, code regenerated) but the logic would never have actually run. Check and set both gates below before considering an assignment done.

Table-level enablement flags — verify, don't assume

Whether a code type's business logic runs at all for a given table is a per-table boolean on the tab entity (data_modeling domain): use_defaults (Default), use_layouts (Layout), use_contexts (Context), use_badges (Badge), use_change_detection (Change detection), use_insert_handlers/use_update_handlers/use_delete_handlers (Handlers). These are the model's real names for the "Use default/layout/context/… concept" checkboxes shown in the Software Factory UI at the table level. An existing prog_object row (e.g. default_absence) does NOT imply this flag is on — a table can have a Default prog_object (framework defaults_start/defaults_end wrapper only, no real logic) while use_defaults is still false. Check with execute_odata_query against tab ($select=use_defaults,use_layouts,use_contexts,use_badges,use_change_detection, use_insert_handlers,use_update_handlers,use_delete_handlers) before declaring an assignment complete, and enable any that are off via stage_resource(edit)/patch_resource/commit_resource on the tab row, then re-run generate_code_grp.

Per-column enablement flags — verify, don't assume

Whether a specific column actually participates in a code type's business-logic variables is a separate, per-column setting, exposed as boolean flags on the col entity (data_modeling domain): default_input/default_output (Default), layout_input/layout_type_output/layout_mand_output (Layout), context_input (Context), function_input (function/task parameters). These are the model's real names for what's shown in the Software Factory UI as "Default"/"Layout"/"Context" checkboxes on a column. Do not assume a newly-added or existing column has these on — check them with execute_odata_query against col ($select=default_input,default_output,layout_input,...) before writing a template that references @[col_id]/p_[col_id] for that column, and again after if the flags were off, since a control procedure referencing a column whose corresponding input/output flag is disabled either won't have that variable generated at all or won't have the assignment persisted back to the column. If a flag is off and the logic genuinely needs it, enable it via stage_resource(edit)/patch_resource/commit_resource on the col row first, then write/assign the template.

Column flags being on is not sufficient by itself — see the table-level flags above. A column can have default_input/default_output = true while the table's use_defaults = false, in which case the assigned logic still won't run. Check both.

Variables — three different things, resolved at three different moments

1. Template [PARMTR] — plain text substitution at code-generation time, before compilation. Filled per static assignment or per SQL-assignment query row. Can substitute a column/table name, not just a value — a bare numeric literal works too (e.g. dateadd(day,[days],@date_from)).
2. Business-logic variables — real stored-procedure parameters (@activated, @badge_value, …), resolved at runtime. Set depends entirely on code type (below).
3. Generated session variables — session-scoped context available in any logic concept via SESSION_CONTEXT(N'…') (SQL Server) or current_setting('…', true) (PostgreSQL): tsf_appl_id, tsf_appl_alias, tsf_appl_lang_id, tsf_global_lang_id, tsf_client_instance_id, tsf_ipv4/ tsf_ipv6, tsf_is_public_request, tsf_original_login, tsf_use_log_session_id, tsf_guid (deprecated).

Business-logic variables by code type

Full per-code-type input/output variable table (Default, Layout, Context, Trigger/event, Handler, Change detection, Badge, Process, Task), the Handler-Update PK-parameter gotcha (@upd_[pk_col_id] vs. @[pk_col_id]), the @cursor_from_col_id initial-default-vs-reactive-recompute pattern, and the dialect-dependent variable-name-prefix note (@[col_id] T-SQL vs. p_[col_id] PostgreSQL) all live in references/code_type_variables.md — read it once the target code type is known, to get the exact input/output variable names for that code type before writing the template body.

Assignment types

• Static: Assigning tab → search the task/view/subject/column/other object → attach the template → fill [PARMTR] values. Check "Ignore if empty" on a parameter to drop that line entirely when no value is given, instead of emitting an empty string.
• Dynamic (SQL): write into the staging tables backing prog_object, prog_object_item, and prog_object_item_parmtr. A parameter can fan out into multiple rows (e.g. one line per column in a table) — the main reason to reach for SQL assignment over static.
• [PARMTR] parameters auto-generate on the Parameters tab the moment they're typed into a template; an icon flags any still missing a value. Run Generate parameters if they didn't appear automatically.

Static assignment via API — the actual entities involved

control_proc_template.type_of_object/object_id look like the assignment mechanism (the entity description calls them out explicitly), but in practice static assignment for column-level logic (Default, Layout, Context, …) is wired through a different pair of entities — verified against a real PostgreSQL model via sf_mcp/manage_functionality:

• template_prog_object_item — the actual junction. Key: (model_id, branch_id, rdbms_type, prog_object_id, prog_object_item_id); scalar: control_proc_id, template_id, order_no. One row = "this template contributes code, at this position, inside this generated program object" (e.g. prog_object_id = 'default_absence' is the whole table's generated Default procedure; framework wrapper items defaults_start/defaults_end bookend it at order_no 1 and 100000 — pick something in between). prog_object_item_id just needs to be unique per (rdbms_type, prog_object_id); reusing the template_id as the item id is a reasonable default. The same low/high bookend split works for your own templates too, not just the framework's: on a Handler, assigning one template at a very low order_no (pre-mutation validation) and another at a very high one (post-mutation follow-up) brackets the framework's own auto-generated insert/update/ delete statement, which sits somewhere in between at a position you don't control. A pre-mutation template runs before the framework's transaction wrapper has opened one — an unconditional rollback transaction there errors with nothing to roll back; guard it with if @@trancount > 0 rollback transaction, never call it bare. All templates assigned to the same prog_object_id concatenate into one generated procedure body, in order_no order — a local variable declared in the low-order_no template is visible to the high-order_no one on the same object, a legitimate way to carry a captured value (e.g. the row's pre-mutation state) from a pre-mutation template through to a post-mutation one. Don't set the pre-mutation template's order_no equal to the framework's own low-end wrapper item (typically 1 for a Handler's handler_start) — verified live, a tie doesn't sort by intent. When two items share an order_no, the platform breaks the tie alphabetically by prog_object_item_id, not by which one you meant to run first — a custom item whose id happens to sort before the framework wrapper's id renders before the generated procedure's own header and parameter list, referencing parameters that aren't in scope yet, and fails at deploy time (not at generation time). Query prog_object_item for the target prog_object_id first to see the framework wrapper items' actual order_nos (e.g. handler_start at 1, transaction_start at 2, the generated statement itself around 1000), and pick a value strictly between two of them — e.g. 5, safely after both handler_start and transaction_start and well before the generated statement — so placement never depends on an alphabetical tie-break. The same <type>_<owner_id> naming extends to tasks, not just tables — a task's own code-type placeholders are task_<task_id> (the Task code type itself), default_<task_id>, layout_<task_id>, badge_<task_id>, etc.
• template_prog_object_item_parmtr — child of the row above (same compound key + prog_object_item_parmtr_id, an auto int64). Holds parmtr_id/parmtr_value pairs: parmtr_id must match a [bracket_token] used literally in the template's template_code (case-sensitive, no @ or other decoration inside the brackets — just the bare name), parmtr_value is the literal text substituted in at generation time.
• prog_object rows (e.g. default_absence) already exist once the table has ever been generated — check with execute_odata_query before assuming a Generate code group pass is needed.
• A direct write (add) to template_prog_object_item can be rejected outright, even though it's the actual junction described above. Verified live: a working fallback mirrors the Assigning screen instead of writing the junction table directly — find the read-only "assigning overview" row for the target object and control procedure (one row per (rdbms_type, prog_object_id, control_proc_id), showing which templates are available and how many are already assigned), then invoke its bound "add this template's assignment" action for the specific template_id. That action writes the same template_prog_object_item row through a task instead of a raw insert, and succeeded where the direct write didn't. This isn't universal — confirmed live in another session that a plain direct add succeeded with no rejection across seven separate assignments on the same model. Try the direct add first; only reach for the Assigning-screen fallback above if it actually errors.
• A direct edit to template_prog_object_item.order_no (to reorder an already-assigned template) can be rejected the same way as an add, verified live. The working fallback is the same "overview" pattern as above, one level down: the assigned-templates overview row for that object (keyed by rdbms_type/prog_object_id/the assigning control procedure/prog_object_item_id, one row per assignment already made, distinct from the "available templates" overview used for adding) exposes order_no as a plain editable field. Edit it there instead of retrying the direct edit.
• Generating code is two distinct tasks, not one — see "Actually generating code" below before calling either. An earlier version of this doc claimed a single task_generate_code_grp call regenerates prog_object.prog_object_generated_code; verified live that this is wrong for a brand-new object.

Actually generating code — two distinct tasks, don't conflate them

Verified live against sf_dev_wiz_mcp/a real model, after the simpler single-task assumption above silently failed to produce any code for a table/view generated for the very first time this session.

1. task_generate_code_grp, bound to control_proc — address it with just (model_id, branch_id, control_proc_id), no prog_object_id required. Use any control procedure in the target code group: your own new one, or the group's framework meta control procedure (e.g. pg_views for VIEWS). This materializes any missing prog_object placeholder row(s) for objects in that code group — exactly the row that doesn't exist yet for something created this session, and that nothing else lets you create directly (prog_object itself: stage_resource(add) → immediate 403, before any field can even be set; the job-based task below: needs a prog_object_id that doesn't exist yet — chicken-and-egg). This step alone does not generate code. Verified: calling it — even twice, even bound to the framework's own pg_views — left prog_object.generated_code_stale = true, prog_object_generated_code empty, and queued nothing in generate_object_code. Its only job is to make the target object addressable for the next step. A commit of this task can also report a transport-level timeout to the caller even though it completed successfully server-side — verified live: the timed-out call had already created the placeholder row. Don't treat a timeout as proof of failure; re-query for the expected row before retrying or working around it.
2. task_add_job_to_generate_object_code, bound to prog_object_code (or prog_object_overview) — address it with (model_id, branch_id, rdbms_type, prog_object_id), now resolvable because step 1 created the row. This is the task that actually queues a generation job and produces code.
   • The job lands in the generate_object_code entity set: key job_id; status field generate_object_code_status (byte enum scheduled 0, executing 1, wait_for_user 2, successful 3, failed 4, cancelled 5, aborted 6, warning 7, info 8) plus a human-readable generate_object_code_status_name. No timestamp field is exposed on this entity — query $orderby=job_id desc to find the job just queued, and confirm generate_object_code_status = 3 ("Successful"). This entity set may not resolve live under that name — verified on one connector, only a generate_object_code_log entity was found (a pure error log: job_id, error_no, error_msg, no status field at all). Don't spend time hunting for the job-status entity by name; skip straight to the simpler check below, which is sufficient on its own.
   • Confirm the actual output by re-reading the prog_object row afterward: generated_code_stale should now be false, and prog_object_generated_code should hold the real generated SQL text.
   • prog_object.control_proc_id is not useful for confirming your own assignment landed — it reflects whichever control procedure owns that code group's structural wrapper (the framework meta-procedure that also generates the _start/_end items), regardless of which procedure you used to trigger task_generate_code_grp and regardless of what your own template is assigned to. Verify your own logic made it in via template_prog_object_item/prog_object_item, or by reading the generated code text — not by checking who this field says owns the object.
   • The same misleading field trips you up the other way round too: finding the real control procedure/template behind an existing task/object to edit its logic. prog_object_code's own control_proc_id for that row will just as often point at the framework wrapper (e.g. a generic per-code-type dispatcher), not the specific logic you actually want to change. The reliable way to find the real owner: read the generated prog_object_generated_code text itself — it contains header comments (--control_proc_id: ..., --template_id: ..., --prog_object_item_id: ...) naming the actual control procedure and template that produced that section of code. Look those exact names up directly in control_proc/control_proc_template rather than trusting any control_proc_id field on prog_object/prog_object_code.
3. Order matters, and step 1 is only needed once per brand-new object. Once a prog_object row exists — any table/view/task that's ever been generated before — skip straight to step 2 for every later template or assignment change. Step 1 is specifically the fix for the chicken-and-egg gap on an object generated for the very first time.
4. prog_object is not directly writable through this API. Don't try to hand-create or edit the placeholder row to work around the above — it returns 403 immediately. Always go through step 1 instead. 4a. Known gap, verified live: a brand-new standalone subroutine (PROCEDURES/FUNCTIONS/ TABLE_VALUED_FUNCTIONS code group) with no existing table/view/task to hang off of may never get its placeholder prog_object materialized this way. Unlike table/view/task-scoped code types, where step 1 reliably creates the missing placeholder, two different attempts both failed to produce one for a genuinely new subroutine: task_generate_code_grp bound to the group's own framework control procedure (the same recipe that works for VIEWS/HANDLERS/etc.), and a separate unbound whole-branch "generate new objects"-style task. Neither errored — they simply left no prog_object row behind to address in step 2. The control procedure, its template, and the SQL logic itself can still be fully authored and reviewed through the API; only the deployable object couldn't be materialized this way. Treat this as needing a manual generate pass in the Software Factory's own UI, and say so, rather than continuing to retry alternate API paths.
5. After wiring a brand-new static assignment (template_prog_object_item) onto an object whose placeholder was bootstrapped in step 1 using a different (e.g. framework) control procedure, re-run step 1 again — this time bound to your own new control procedure — before running step 2. Verified live: generating right after step 1 was run only with the framework's bootstrap control procedure produced a successful status and a generated_code_stale = false object, but the generated code contained only the framework's wrapper/bookend fragments (e.g. the group's _start/_end items) — the newly-assigned template's own logic was silently missing. The assignment had been written correctly (template_prog_object_item looked right on inspection), but prog_object_item itself hadn't been re-synced to include it yet. Re-running step 1 bound to the real control procedure (not the bootstrap one) picked up the assignment; step 2 then produced the correct, complete code. Don't treat a successful status alone as proof the right logic made it in — read the generated text and confirm your own template's content is actually present, not just that generation didn't error.

Reuse — decide in this order, before writing anything new

1. Reuse as-is. An existing template already does exactly what's needed — add an assignment to the new program object, nothing new written or reviewed.
2. Reuse with parameters. An existing template is right but for a different column/object — if it's already parameterized, add an assignment and supply the parameter values.
3. Generalize a near-match. A template is one specific case of a more general rule — promote the hardcoded parts to [PARMTR]s and re-assign it, including back to its original object with that object's own values, so both uses share one template.
4. Write new. Only once the above are ruled out — and even then, parameterize the object-specific parts so the next reuse doesn't require writing another one.

Search the model's existing control procedures/templates by purpose, not by object name, before concluding nothing fits — a well-named template describes what it does.

Reuse one template across many assignments instead of duplicating it. If the same logic applies to several columns/tables (e.g. "default this date column to today" on both absence.start_date and lead.converted_date), write the template once with a [PARMTR]-style placeholder standing in for the column's business-logic variable name:

if [date_col] is null then
    [date_col] := current_date;
end if;

Then create one template_prog_object_item row per target (rdbms_type, prog_object_id), all pointing at the same control_proc_id/template_id, and give each one its own template_prog_object_item_parmtr row: parmtr_id = 'date_col', parmtr_value = 'p_start_date' for the absence assignment, parmtr_value = 'p_converted_date' for the lead assignment. Verified production pattern for this: refresh_after_execute_tasks (model 62903_TASKS_AND_REPORTS) — one template assigned to four different task prog_objects, each supplying a different TASK_NAME value via its own parameter row. Don't default to "one template per column" — that duplicates code that should live in one place and just be re-parametrized per assignment.

Adding new logic to an object that already has a large existing template? Add a second template instead of editing the first in place. A control procedure can have more than one control_proc_template, each assigned to the same (or a different) prog_object_id at its own order_no — this isn't limited to the reuse-across-assignments case above. When the change is purely additive (new statements that don't depend on rewriting what's already there), create a new template under the same control_proc_id, assign it through the normal static-assignment flow, and position it relative to the existing item(s)' order_no (query prog_object_item first to see what's already there, including any framework wrapper items). This avoids reading back and hand-reconstructing a long existing template_code field from truncation-safe chunked reads just to safely append to it — a real risk of introducing a transcription error into an otherwise-working script. Verified live on an UPGRADE-group object seeding hundreds of lines of demo data across two existing templates; a third, purely-additive template slotted in cleanly at a chosen order_no between them.

Can't find the program object to assign to? A table/view/task/subroutine just created doesn't have Layout/Default/Handler/etc. program objects yet — those prog_object rows only exist after a generation pass, not from creating the object itself. Run the Generate code group task (task_generate_code_grp) for the relevant code group first — invokable from any control procedure in that group, or directly from the Assigning screen (static_assignment_overview). This creates the missing prog_object placeholder(s) so you have something to assign to — it does not itself produce prog_object_generated_code; see "Actually generating code" above for the second, job-based task that's still needed to produce real code afterward. Applies any time a target can't be found: run this before concluding something's broken.

Creating a brand-new Task (not just assigning logic to an existing one)

A Task is its own top-level meta-object, separate from where it's bound and from its parameters — verified live, this order is not optional:

1. Create the task row first — keyed only by (model_id, branch_id, task_id), independent of any table. This is the master object; nothing else about the task can exist before it does.
2. Bind it to a table via tab_task — keyed by (model_id, branch_id, tab_id, task_id). Setting tab_task.task_id to a task_id that doesn't exist yet is rejected outright (a 403-style error), even though the field presents as an ordinary editable string — it's enforcing that the task row exists first, not just validating the string shape.
3. Add its parameters via task_parmtr — keyed by (model_id, branch_id, task_id, task_parmtr_id), a child of task, not of tab_task. If a parent-based add doesn't resolve a nav to task, fall back to a plain add with the full key supplied as explicit fields (see thinkwise_datamodeling_guidelines's note on this same weak-entity fallback). Each parameter needs dom_id (the domain backing its type/control) and mand set explicitly; confirm task_input/task_output for output-only parameters rather than trusting the default. A task bound to a table via tab_task does not automatically receive that table's primary key as an input — unlike a Handler, which gets the row's key for free (see the code-type variable table above). If the task's logic needs to know which row it's acting on, add a task_parmtr whose id m

…(truncated)