Select Fields and Assign Field Properties

you select fields and assign field properties as you build your application this section covers the application and applet fields and the options they provide for setup on the field properties tab the fields you use to build your application are the fields that users will access when they create or edit records in swimlane here is a screenshot of a new swimlane record with multiple fields available to fill out field keys field keys function as aliases for fields they allow for consistent data ingestion, product upgrades, and imports of applications across different environments field keys are validated for uniqueness against other field keys and field display names within an application (they can be the same as their corresponding display name) they can be a maximum of 32 characters and can only contain lower case letters numbers hyphens underscores when you first create a field, swimlane names the field key based on the field display name upper case letters are converted to lower case, spaces are replaced with dashes, and non alphanumeric characters are removed you can change the field key value at this time, if desired administrators can change field keys within application builder by de selecting the lock icon the field key value, once unlocked, can be changed this lock allows changes to the display name of field to be made without affecting the field key value if an application is imported from an older version of swimlane and duplicate key field values would be created based on the established display name values, integers will be added the field to prevent duplication (for example, field, field2) if the field key exceeds 32 characters, it is truncated at 29 characters, with integers added to the end as needed application field limit each search indexed field that you add counts toward the tenant application field limit (default 500 ) when the limit is reached, additional field types that count toward the limit are unavailable until you remove fields or an administrator increases the limit under tenant settings > system for the counter, count rules, and save validation behavior, see application builder docid 6q6y4 02l v2khn80gmo5 for the tenant setting and permissions, see tenant system settings docid\ roqfi96efojbqstjig2qt datetime field triggers starting in turbine 26 3 0 , you can configure a date/time field so that a playbook flow runs when the field value (plus an optional offset) is reached this capability is phase 1 of sla tracking time based playbook triggering only dedicated sla field types arrive in later releases datetime field triggers apply only to date/time fields ( datetime input type) they are not available for date only fields or system fields such as first created or last updated what happens when you configure a datetime field trigger you set an offset , unit , and target playbook / flow on the date/time field in application builder when you save the application , turbine adds a datetime field trigger to the selected flow automatically when a record is created or updated with a date/time value, turbine schedules a run for that record at the computed fire time when the fire time is reached, the selected flow runs for that record runs currently appear with trigger type delay trigger (canvas label is datetime field trigger ) the run receives the full record (schema and field values), so later steps can map fields from the datetime field trigger output like a record event trigger—not tracking id only the datetime field trigger on the playbook canvas is system managed you cannot add it from the standard canvas add panel configure and change it from the application field settings see triggers docid\ sedgthtxrzuohzsuvhad4 record data available to downstream steps when the datetime field trigger fires, turbine passes the complete application record into the playbook run field values and schema are available for mapping in subsequent actions mapping works like a record event trigger select fields from the trigger output instead of fetching the record from tracking id alone the tracking id is still present as part of the record data see also triggers docid\ sedgthtxrzuohzsuvhad4 (record data passed to the playbook) configure a datetime field trigger on a date/time field open the application in application builder select a date/time field on the field properties tab, expand advanced under trigger playbook , click configure in the configuration dialog, set offset — whole number of minutes or hours relative to the field value unit — minutes or hours choose playbook — the playbook that will run flow — the flow within a solution playbook (or create a new flow) classic playbooks do not require a separate flow selection click save in the dialog save the application so turbine can sync the datetime field trigger onto the selected flow tooltip on trigger playbook automatically trigger a playbook flow from this field by configuring the target playbook, flow, and optional offset offset behavior offset meaning 0 fire at the date/time field value positive (for example, 2 hours) fire after the field value negative (for example, 30 minutes) fire before the field value rules offset must be a whole number absolute duration cannot exceed 7 days (ui hint cannot exceed 7 days ) dialog units are minutes and hours only record create, update, and delete behavior record change datetime field trigger scheduling create with a date/time value schedules a pending run for that record and field update that changes the date/time value reschedules (or cancels and recreates) the pending run using the new value and configured offset update that clears the date/time value cancels the pending run for that record and field delete the record cancels any pending datetime field trigger run for that record field and playbook lifecycle change result delete the date/time field (or clear its datetime field trigger configuration) pending schedules for that field are cancelled; the datetime field trigger is removed from the linked flow delete or disable the linked playbook or flow turbine clears the datetime field trigger configuration from affected application fields and warns about impact before you confirm cut or copy flows that use a datetime field trigger cut and copy are disabled for flows that have a datetime field trigger phase 1 scope supports time based triggering from a date/time field value (± offset) does not introduce dedicated sla field types or full sla tracking workflows; those are planned for later releases see also triggers docid\ sedgthtxrzuohzsuvhad4 — datetime field trigger overview and canvas behavior configuring playbooks docid\ iqsgpto 17szz7k8ktrai — playbook configuration entry points application builder docid 6q6y4 02l v2khn80gmo5 — building applications and fields schedule triggers https //docs swimlane com/schedule triggers — cron and recurring schedules (separate from datetime field triggers)