--- title: How to create tasks, records and links from a workflow url: https://tideswell.xyz/docs/workflows/create-tasks-and-records description: Four actions that write. Create a task, create any record, update a field, or connect two records together. --- > Documentation index: fetch https://tideswell.xyz/llms.txt to discover every page before exploring further. # How to create tasks, records and links from a workflow Four steps do the writing. One is in **Actions** and three are in **Advanced**, and together they cover most of what a workflow is for. ## Create task [#create-task] Creates a task in a department you choose, optionally assigned to somebody, with a priority, a description and a due date a set number of days out. Set the **department** deliberately: it decides who can edit the task afterwards, per . Put values from the triggering record in the title, per . A generic title makes a queue nobody can triage. Every task a workflow creates carries a line saying which record it came from, so it is never mistaken for a task a person raised. That line is also how somebody finds the record when the title is not enough. Publishing refuses a Create task with no title or no department. ## Update a field [#update-a-field] Sets one field on the record that started the workflow, including moving a custom record to a different status. This is how a record moves itself along. A fabric trial whose lab results come back within tolerance can set its own status to Approved rather than waiting for somebody to notice. It writes to the **triggering** record only. ## Create any record [#create-any-record] Creates a record of any type your workspace allows, filling its fields from the triggering record. Use it when one thing should always produce another. An approved fabric trial creating a production run, with the fabric, the supplier and the date carried across. Publishing refuses one that is missing a required field. ## Connect two records [#connect-two-records] Links two records so each one shows the other, which is the same relationship the Related panel displays. See . This is the quiet workhorse. A sample request linked to its supplier on creation means nobody has to remember, and six months later the supplier's record shows every sample ever requested from them. ## What can none of them do? [#what-can-none-of-them-do] Reach a different record to work on. Every step reads and writes the record that set the workflow off, and the panel says as much. Fields that link to another record cannot be set, the same restriction as on conditions. The builder hides them and publishing refuses them. ## Whose permissions do these use? [#whose-permissions-do-these-use] The workflow **owner's**. Every action is carried out with that person's access, and a run says so on screen. Two consequences worth planning for. A workflow can create a task in a department its owner can write to, and not in one they cannot. And if the owner leaves the workspace or loses a permission, the action fails **visibly** on the run rather than quietly doing nothing. Own workflows with an account that has the access the workflow needs, and check them when somebody leaves. ## What if it keeps setting itself off? [#what-if-it-keeps-setting-itself-off] A workflow that updates a field on the record that triggered it can trigger itself, which is the classic loop. There is a guard: a workflow that has run five times for the same record, or fifty times overall, within a short window is refused. Those refused runs are dropped rather than queued, so they do not arrive later in a flood. A run that goes over fifty steps stops and tells you to check it for a loop. The fix is watched fields on the trigger. Tick only the fields that should cause a run, and a workflow writing to a different field cannot set itself off. See .