On Save: Difference between revisions
Marek Rodak (talk | contribs) |
Marek Rodak (talk | contribs) No edit summary |
||
| (4 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
{{Rules TOC}} | {{Rules TOC}} | ||
<span style="float:left; padding-right:10px">[[File:On Save icon.PNG|100 px]]</span> | <span style="float:left; padding-right:10px">[[File:On Save icon.PNG|alt=On Save icon|100 px]]</span> | ||
Rules are client-side scripts (no-code [[business logic]]) that are executed when a user of the mobile app interacts with the app. The '''On Save''' rules are checked when you save a record. Rules are managed using the [[rules editor]], usually in [[Woodford]]. | Rules are client-side scripts (no-code [[business logic]]) that are executed when a user of the mobile app interacts with the app. The '''On Save''' rules are checked when you save a record. Rules are managed using the [[rules editor]], usually in [[Woodford]]. | ||
{{clear|left}} | {{clear|left}} | ||
| Line 47: | Line 47: | ||
This rule shows a warning message if the phone format is not correct. As this is only a warning, users can ignore it and save the record anyway. | This rule shows a warning message if the phone format is not correct. As this is only a warning, users can ignore it and save the record anyway. | ||
[[File:Warrning message example.PNG|600px]] | [[File:Warrning message example.PNG|alt=On Save: Main phone field validation rule example(warning message example)|600px]] | ||
=== Example: Check related entity before saving === | === Example: Check related entity before saving === | ||
| Line 57: | Line 57: | ||
If the Main Phone field does not contain any data or does not match regex, assign the "Red" style to the field. Otherwise, assign "Table" as style. | If the Main Phone field does not contain any data or does not match regex, assign the "Red" style to the field. Otherwise, assign "Table" as style. | ||
[[File:Style validation of mobile phone.PNG|600px]] | [[File:Style validation of mobile phone.PNG|alt=On Save: Validating field with style rule example|600px]] | ||
===Example: Validation of date fields=== | ===Example: Validation of date fields=== | ||
| Line 65: | Line 65: | ||
We create a DateTime variable called Today, set to today. If the field lastonholdtime value is in the future, we set the focus on the field and display error message. | We create a DateTime variable called Today, set to today. If the field lastonholdtime value is in the future, we set the focus on the field and display error message. | ||
[[File:OnSaveLastOnHoldDate.PNG|600px]] | [[File:OnSaveLastOnHoldDate.PNG|alt=On Save: Validation of date fields rule example|600px]] | ||
=== Example: Automatically schedule a task while saving a new lead === | === Example: Automatically schedule a task while saving a new lead === | ||
| Line 71: | Line 71: | ||
If the Lead is new, we create a new task via NewInstance. Then we use steps to fill in the necessary information for the newTask. In the end, we add a step to save the Task after the Lead (since the task can only refer to an already existing record). | If the Lead is new, we create a new task via NewInstance. Then we use steps to fill in the necessary information for the newTask. In the end, we add a step to save the Task after the Lead (since the task can only refer to an already existing record). | ||
[[File:Schedule a task.PNG|600px]] | [[File:Schedule a task.PNG|alt=On Save: Automatically schedule a task while saving a new lead rule example|600px]] | ||
To see the rule execution in the app, click [https://www.youtube.com/watch?v=13WDlW4zSfg here]. | |||
=== Example: Detect record duplicity=== | |||
[[File:Already existing account check.PNG|600px]] | Create a variable with the LoadFetch operator, where we look for an account with the same name but a different ID. If there is an account like this, display the warning message. | ||
[[File:Already existing account check.PNG|alt=On Save: Detect record duplicity rule example|600px]] | |||
Used Fetch: | Used Fetch: | ||
[[File:Already existing account check Fetch.PNG|600px]] | [[File:Already existing account check Fetch.PNG|alt=On Save: Detect record duplicity rule example (used fetch)|600px]] | ||
To see the rule execution in the app, click [https://www.youtube.com/watch?v=g7G2YjBKet0 here]. | |||
== Views == | == Views == | ||
| Line 91: | Line 95: | ||
Set the email field as edit or directedit type. If the email field does not match regex, an error message will pop up. | Set the email field as edit or directedit type. If the email field does not match regex, an error message will pop up. | ||
[[File:OnSaveViewValidation.PNG|600px]] | [[File:OnSaveViewValidation.PNG|alt=On Save: Email field validation on the view rule example|600px]] | ||
== Questionnaires == | == Questionnaires == | ||
| Line 107: | Line 111: | ||
If the next inspection date question is filled in, a new task with data loaded from the questionnaire is created. | If the next inspection date question is filled in, a new task with data loaded from the questionnaire is created. | ||
[[File:OnSave newTask.PNG|600px]] | [[File:OnSave newTask.PNG|alt=On Save: Create a new task based on next inspection rule example|600px]] | ||
=== Example: Measure the duration of inspection === | === Example: Measure the duration of inspection === | ||
| Line 117: | Line 121: | ||
We create a shared variable StartInspection, where we assign the current time (by SetNow). We then assign this value to the start-of-inspection question. | We create a shared variable StartInspection, where we assign the current time (by SetNow). We then assign this value to the start-of-inspection question. | ||
[[File:Inspection start time.PNG|600px]] | [[File:Inspection start time.PNG|alt=On Save: Measure the duration of inspection (On Load part)|600px]] | ||
;On Save part: | ;On Save part: | ||
| Line 123: | Line 127: | ||
We create a shared variable EndInspection, where we assign the current time (by SetNow). We then assign this value to the end-of-inspection question. We then create a variable var2 where we calculate the time difference between StartInspection and EndInspection (the result is set to be in minutes). In the end, we assign var2 to question inspection.time. | We create a shared variable EndInspection, where we assign the current time (by SetNow). We then assign this value to the end-of-inspection question. We then create a variable var2 where we calculate the time difference between StartInspection and EndInspection (the result is set to be in minutes). In the end, we assign var2 to question inspection.time. | ||
[[File:Inspection end time.PNG|600px]] | [[File:Inspection end time.PNG|alt=On Save: Measure the duration of inspection (On Save part)|600px]] | ||
{{Note|Questions start-of-inspection and end-of-inspection are optional. They are not required for the rule to work.}} | {{Note|Questions start-of-inspection and end-of-inspection are optional. They are not required for the rule to work.}} | ||
| Line 131: | Line 135: | ||
In the following example, we're using the [[Rules_editor#Questionnaire_variables|questionnaire variable]] <code>QuestionGroups</code> to access group data. Notably, it uses <code>QuestionGroups.{group name}.All</code> to access all instances of a repeatable group. In the questionnaire "Assets Inspection", one repeatable group is used for each asset. Within each instance of this group, the yes/no question "issue-encountered" holds information on whether the asset is okay. This way, we can use a simple On Save rule to check the status of all instances of the repeatable group and set a suitable questionnaire result. | In the following example, we're using the [[Rules_editor#Questionnaire_variables|questionnaire variable]] <code>QuestionGroups</code> to access group data. Notably, it uses <code>QuestionGroups.{group name}.All</code> to access all instances of a repeatable group. In the questionnaire "Assets Inspection", one repeatable group is used for each asset. Within each instance of this group, the yes/no question "issue-encountered" holds information on whether the asset is okay. This way, we can use a simple On Save rule to check the status of all instances of the repeatable group and set a suitable questionnaire result. | ||
[[File:Questiongroup example.png|600px]] | [[File:Questiongroup example.png|alt=On Save: Check all instances of a repeatable group rule example|600px]] | ||
=== Example: Create new workorder if next inspection is necessary === | === Example: Create new workorder if next inspection is necessary === | ||
| Line 138: | Line 142: | ||
If the next inspection is necessary and recommended date of the next inspection is filled in, a new workorder is created. | If the next inspection is necessary and recommended date of the next inspection is filled in, a new workorder is created. | ||
[[File:RegardingObjectLookup OnSave.PNG|600px]] | [[File:RegardingObjectLookup OnSave.PNG|alt=On Save: Create new workorder if next inspection is necessary rule example|600px]] | ||
{{Feedback}} | |||
Latest revision as of 14:19, 20 November 2023
| Rules and examples |
|---|
|
Rules are client-side scripts (no-code business logic) that are executed when a user of the mobile app interacts with the app. The On Save rules are checked when you save a record. Rules are managed using the rules editor, usually in Woodford.
On Save rules are available for the following user interface components:
- Forms
- Editable views
- Questionnaires
Save action
To understand On Save rules, it is important to understand how the saving of records works in Resco mobile apps. This is the order of events when saving:
- User initiates the saving process.
- On Save rules are executed.
- The app checks whether the record can be saved (rules may interrupt save).
- If valid, the record is saved.
SaveAfter
SaveAfter defines an event in which a certain action is performed after saving (the form or questionnaire). This event is typically used in the case of a referential (look-up) entity. For example, we want to save a new Lead. We have On Save rule where we create a Task to remind us to contact the Lead. If something goes wrong during save, we will have Task without Lead. SaveAfter ensures that the Lead is saved first and only then the Task, as empty references cause errors.
- Available only for On Save and On Execute rules.
- In questionnaires, available for root questions (and not for question groups)
Display validation problems
There are two built-in string variables that can be used to display validation problems:
- ErrorMessage: A string variable where you can set an error message for form. In the case of On Save event, this stops the saving.
ErrorMessage Assign Website URL cannot be empty!
- WarningMessage: A string variable where you can set an error message for form. In the case of On Save event, this does not prevent saving, user can decide to continue.
WarningMessage Assign Website URL is empty! Continue anyway?
Forms
Form is a screen in the application that contains numerous fields that either hold or await the data. The default behavior of an entity form can be changed using form rules. Form rules describe sequences of steps that are executed on form-related events. On Save usually serves as a final field validation or they can automate changes in related records.
- Rule execution
- When you save a record.
Example: Main phone field validation
This rule shows a warning message if the phone format is not correct. As this is only a warning, users can ignore it and save the record anyway.
This somewhat dated blog shows how to check a related record before you can save changes. Blog
Example: Validating field with style
If the Main Phone field does not contain any data or does not match regex, assign the "Red" style to the field. Otherwise, assign "Table" as style.
Example: Validation of date fields
In this example, we validate the date filed where the date is supposed to be in past.
We create a DateTime variable called Today, set to today. If the field lastonholdtime value is in the future, we set the focus on the field and display error message.
Example: Automatically schedule a task while saving a new lead
If the Lead is new, we create a new task via NewInstance. Then we use steps to fill in the necessary information for the newTask. In the end, we add a step to save the Task after the Lead (since the task can only refer to an already existing record).
To see the rule execution in the app, click here.
Example: Detect record duplicity
Create a variable with the LoadFetch operator, where we look for an account with the same name but a different ID. If there is an account like this, display the warning message.
Used Fetch:
To see the rule execution in the app, click here.
Views
On Save rules can be used with views, but only when the Editable field is set. (Editable field, list, or editable grid is a feature that allows users to edit one or more records directly from the view, without a need to go to the form of a record.)
Example: Email field validation
Set the email field as edit or directedit type. If the email field does not match regex, an error message will pop up.
Questionnaires
In inspections, there are two options for when to execute On Save rules.
- Rule execution
- When you complete the questionnaire.
- When you save or complete the questionnaire.
This behavior is configured on the questionnaire level, in the Validate On property.
Example: Create a new task based on next inspection
If the next inspection date question is filled in, a new task with data loaded from the questionnaire is created.
Example: Measure the duration of inspection
This rule measures the time duration of an inspection. Since the rule has to contain the start and end of the inspection, we need to include both On Load and On Save.
- On Load part
We create a shared variable StartInspection, where we assign the current time (by SetNow). We then assign this value to the start-of-inspection question.
- On Save part
We create a shared variable EndInspection, where we assign the current time (by SetNow). We then assign this value to the end-of-inspection question. We then create a variable var2 where we calculate the time difference between StartInspection and EndInspection (the result is set to be in minutes). In the end, we assign var2 to question inspection.time.
| Note | Questions start-of-inspection and end-of-inspection are optional. They are not required for the rule to work. |
Example: Check all instances of a repeatable group
In the following example, we're using the questionnaire variable QuestionGroups to access group data. Notably, it uses QuestionGroups.{group name}.All to access all instances of a repeatable group. In the questionnaire "Assets Inspection", one repeatable group is used for each asset. Within each instance of this group, the yes/no question "issue-encountered" holds information on whether the asset is okay. This way, we can use a simple On Save rule to check the status of all instances of the repeatable group and set a suitable questionnaire result.
Example: Create new workorder if next inspection is necessary
This example is an On Save addition to the On Load rule: Populate the questions with data from regarding lookup entity 2. If the next inspection is necessary and recommended date of the next inspection is filled in, a new workorder is created.
{{#CI form: title = Was this information helpful? How can we improve? | type = inputs | [textarea] }}