Create a record
Create a record is an action that makes another record from the one the rule runs on: a case, or with their plugins on an incident, a change (or a standard change from a template), a problem, a task on a change, or a dev task. The new record is linked to the one it came from where the desk links them (an incident, change, problem or dev task to its case), and both show which rule did it.
Some examples:
- A portal form for outages opens a case; a rule on that form's cases declares an incident, linked to the case, so the requester follows the case and the team works the incident.
- A case labelled change request records a change as a draft, for someone to complete and send for approval.
- A rule on changes adds the same tasks to every emergency change: test the rollback, tell the service owner.
- A portal form for VPN access starts a standard change from the approved template "Add a user to the VPN", planned an hour later, so nobody has to type it in.
- A case labelled bug adds a bug to the developers' board, linked to the case, so the case hears when it's fixed.
A form that should declare an incident or record a change can be built with its rule in one go: see Building a form with the guide.
Setting it up
Add the action Create a record and pick what to create. Each kind has its own fields:
| Creates | Fields |
|---|---|
| Case | Subject and requester's email (needed; an address the desk doesn't know gets a new contact), description, unit, priority, team, assignee, labels. |
| Incident | Title (needed), summary, impact, urgency, the unit affected, service, commander. Its priority comes from impact and urgency. Without a commander it starts as New. |
| Change | Title and service (needed), description, type (normal or emergency), owner, implementer, planned start and duration. Without an owner, who the rule runs as owns it. It starts as a draft. |
| Standard change | An approved standard change template (needed), title (empty: the template's name), planned start and duration, a reason if that time is outside the maintenance windows, implementer. It comes with the template's plans and tasks, pre-approved. |
| Problem | Title (needed), description, impact, urgency, unit, service. |
| Change task | On rules that run on changes: the task, and who does it. |
| Dev task | On rules that run on cases: the Board (needed), title, description, type, priority, assignee. It goes in the board's first column. |
The planned start counts from when the rule runs: in an hour, in 4 hours, tomorrow at the same time, in 3 days or in a week, for the duration picked (an hour if none). A change without one is planned later, by hand. A standard change is checked like one started by hand: the template must still be approved, a time in a freeze is refused, and a time outside the service's maintenance windows needs the reason filled in, and then waits for the approval rules' approval. When a check fails, nothing is made and the rule's activity says why.
A unit picked in the fields must be the rule's unit or one below it; left empty, the rule's own unit is used.
Text fields can take placeholders from the record the rule runs on, like {{title}} or {{requester.email}}.
Insert next to a field lists the ones there are:
| Placeholder | On cases | On changes and problems |
|---|---|---|
{{title}} | The subject | The title |
{{ref}} | The reference, like CASE-1042 | The key, like CHG-12 |
{{url}} | A link to the case | A link to it |
{{description}} | The request (the first message, or the form's answers) | |
{{priority}}, {{status}}, {{unit}}, {{labels}} | The case's | |
{{requester.name}}, {{requester.email}}, {{account.name}} | Who asked, and their account | |
{{fields.<key>}} | On rules that run when a form is submitted: that form's answer, like {{fields.impact}} |
A form's answers are only offered on a rule that runs when a form is submitted (under Runs on, pick Form submissions, or the trigger A form is submitted): Insert then lists that form's questions, and nothing from other forms. The answers stay with the case they came in on; what the rule creates gets the text it fills in, so the form's questions never become fields of incidents, changes or problems.
A placeholder with nothing in it is left empty. If a needed field comes out empty, nothing is made and the rule's activity says why.
Who it creates as
A rule creates records as who it runs as: System by default, which may create any of them in the organization. When it runs as a person, that person needs the permission to create that kind of record in the rule's unit (Log new cases, Work on incidents, Work on changes or Open problems; Work on cases for a dev task): saving the rule checks it, and it is checked again each time the rule runs. A dev task also needs a board role that may change tasks (member or owner), and only those boards are offered when you pick one. If they are no longer active or have lost the permission, nothing is made and the activity says so; pick someone who may, or System.
What stops rules running away
- A rule never runs on a record it made itself.
- A record a rule made can lead another rule to make one, and that one another, but no further than 3 in a row.
- One rule makes at most 50 records an hour. Over that, it skips and says so in its activity.
The rule's activity lists each record it made, with a link. A case made by a rule has the source Automation, and its history names the rule. An incident, change or problem made by a rule shows who the rule runs as (System, or the person picked) in its history, and is linked to what it was made from.