Insert Record

Use the Insert Record step to create a new record in any BC table from inside a flow. You point the step at a target table, list the field values you want to set, and the step writes the record and exposes it as an output for the rest of the flow.

A typical pattern: an upstream Parser step pulls values out of an HTTP response, then Insert Record turns those values into a customer, sales line, or whatever the table happens to be. Field values can be plain text or SmartFields like {{customerNo}} that are resolved against the flow's context when the step runs.

Configure the step

Open the flow editor, add Insert Record, and fill in the configuration card.

Description

• Purpose: Make it clear which record this step creates.
• When to fill it: Always. The description shows up in the editor and the execution history.
• Tips: Name the table and the source, for example Create customer from CRM payload.

Table

• Purpose: The table to insert the record into.
• When to fill it: Required. Pick from the standard table lookup.
• Tips: Changing the table resets the Field Values list below and prefills it with one empty row per primary-key field, so you can drop in the key values right away.

Run Triggers

• Purpose: Decide whether BC's standard insert logic runs around the new record — its validations and the table's OnInsert trigger.
• Options:
  • On (default) — full BC behaviour. Validations fire, defaults are applied, and BC fills in the SystemId (and any other auto-generated key) for you.
  • Off — the record is written as-is. Useful for raw imports where you take responsibility for the values yourself.

Configuration Template

• Purpose: Optional. Pre-fill the new record from a RapidStart Configuration Template before your explicit field values are applied.
• When to fill it: Use it when most of the record should follow a template (a customer template, an item template, …) and you only want to override a handful of fields.
• Tips: Anything you list under Field Values below overrides the template for the same field. The lookup only shows templates registered for the configured table; picking one for a different table is rejected when the step runs.

Field Values

A row-numbered list of (Field, Value, Validate) rows. Each row writes one field on the new record.

• Field — pick from the configured table. Obsolete fields are filtered out. Blob, Media (single image), and the like are supported as targets — see Binary fields below.
• Value — plain text. SmartFields like {{customerNo}} are resolved against the flow's context when the step runs. The resolved text is converted into the field's data type (Integer, Decimal, Date, Option, Guid, …) before it is written; an unparseable value ("abc" into a Decimal field, for example) stops the flow with an error. Use the AssistEdit button on the Value column to open a multi-line editor for longer inputs.
• Input Format — optional. Tells the step how to read the value text when it doesn't follow your regional notation — see Input format below.
• Validate — when on, the value runs through the field's standard BC validation. When off, the value is assigned directly. Validations fire in row order, so a row that depends on another row running first should come later. Ignored for binary targets.

Input format

Numbers and dates read from an XML or JSON file usually arrive in the file's notation, not yours. On a German-region system, 1000.00 from an XML invoice is read as one hundred thousand (the dot counts as a thousands separator), and a compact date like 20260716 doesn't parse at all. The Input Format column fixes both: it pins down how the value text is interpreted, independent of the region the flow happens to run under.

Input Format	Use for	Example value
(empty)	Values already in your regional notation — the default, nothing changes	1.000,00 on a German system
9 or xml	XML/JSON notation for numbers, dates, times, and booleans	1000.00, 2026-07-16, true
A date/time pattern, e.g. yyyyMMdd	Compact or fixed-layout dates and times	20260716, 16.07.2026 with dd.MM.yyyy

Patterns are built from the tokens yyyy, yy, MM (month), dd, HH, mm (minute), ss — each digit group has a fixed width — plus literal separators like . or - that must appear in the value exactly as written. Patterns work for Date, Time, and DateTime fields only.

A value that doesn't match the configured format stops the flow with an error naming the value, the field, and the format. There is no silent fallback to your regional notation — that's deliberate, because a half-parsed number that happens to look valid is worse than a stopped flow.

Binary fields (Blob, Media)

You can drop a SmartField placeholder into the Value cell of a Blob or Media field — typically a token like {{pdfBody}} produced by an upstream HTTP step that fetched a file. The step writes the bytes straight into the target field; no extra step or decoding configuration is needed.

The step accepts three shapes:

1. A SmartField that carries binary content (e.g. an HTTP step's response body, or a Document step output). The bytes are written as-is.
2. A SmartField that carries base64 text (e.g. {{base64pdf}} produced by a Parser). The text is decoded and the resulting bytes are written.
3. Literal text in the Value cell. If the text is valid base64, it is decoded; otherwise the raw text is written into the field as UTF-8 bytes.

Tip: when fetching a file from a remote service, prefer the HTTP step's binary-body output (option 1). It avoids an unnecessary base64 round-trip and works with any payload size.

Record ID fields

Some tables link to another record through a field of type Record ID — for example an assignment or log table that can point at any record. To fill such a field, put a single record reference in the Value cell: {{rec}} from an earlier Insert Record step, or {{results}} from an earlier Find Records step (this picks the first found record). AutoFlow assigns the referenced record directly.

Anything else — literal text, or a SmartField that resolves to text — stops the flow with a conversion error, because a Record ID cannot be built from text.

Outputs

Name	Type	Meaning
rec	Reference	The inserted record. Use it as a SmartField reference downstream — for example as the Reference input of a follow-up Modify Record or Delete Record step.

Notes

• Auto-generated keys. With Run Triggers on, BC fills in the SystemId and any auto-incrementing keys for you. Leave the corresponding rows empty in the Field Values list, or remove them if you don't need to pin a specific value.
• Trigger-initialized fields override your values. With Run Triggers on, the table's insert logic runs after your field values are applied — and on documents it stamps fields like Document Date, Order Date, and Posting Date with the work date, overwriting whatever you set (in any format). Set such fields in a follow-up Modify Record step on this step's rec output instead; on a modify, no insert initialization runs and dependent fields (like Due Date) are recalculated consistently.
• Field order matters. With validations on, validating one field can overwrite another. Order your rows so the value you want to win comes last.
• Permissions. The step runs under the permission set of the user who activated the flow — there are no dedicated permissions for the step itself.