DRAFT Sintel Apps Designer – Logic Tab (Overview)

 

This guide walks you through the Logic tab in the Sintel Apps Designer, step-by-step, and explains how to create rules that make your form dynamic (show/hide fields, set required fields, display errors, and more).

When designing a form, you use the Logic tab to create rules that run while a user is completing a form. A rule is made up of:

• Conditions – “When this is true…”
• Steps when conditions are met – “…do this”
• Steps when conditions are not met – “…otherwise do this”

You build logic by adding a rule, defining the conditions, then dragging actions (“steps”) into the relevant area.

 

Step 1: Open the Logic Tab

1. Open your form in the Sintel Apps Designer.
2. Select Logic from the top menu (Layout | Logic | Workflow | Settings).

 

You’ll see:

• A left panel with Conditions and Steps
• A large blank area prompting you to add a rule
• A right panel called Properties

 

Step 2: Create Your First Rule

1. Click the plus (+) button in the centre area (or “Add rule”).
2. A new rule panel opens (often titled New Rule).

 

You will now see three sections:

• Conditions
• Steps when conditions are met
• Steps when conditions are not met

 

On the right, the Properties panel shows rule settings such as rule name and execution behaviour.

 

Step 3: Name the Rule 

In the right-hand Properties panel, give the rule a clear name.

Use a consistent naming style like:

• Show Project Details when Request Type = Project
• Make Cost Code required when Department = Finance
• Hide Approval Section unless Status = Submitted

 

Good names make future maintenance much easier.

Step 4: Add a Condition

 

In the left panel, ensure Conditions is selected.

You’ll typically see condition types such as:

• Field value check
• Form mode (New, Edit, View)
• Author
• Group membership
• Workflow status
• Related list item count
• External user
• Attachment count
• Custom JS (advanced)

 

Example: Section Change the Visbility

1. Drag Section Visibility into the Conditions area.
2. Configure it:
   • Choose the field
   • Choose an operator (equals, contains, greater than, etc.)
   • Enter/select the comparison value

Tip: Start simple. Most forms can be handled with Field Value Check + a small number of steps.

 

Step 5: Add Steps (Actions)

Now you define what happens.

In the left panel, select Steps.
Steps are grouped by area, for example:

Form

• Form features
• Ignore validation

 

Section

• Set section title
• Set section description
• Set section visibility
• Set section state

 

Field

• Set field label
• Set field visibility
• Set field state
• Set custom error for field

 

Related list

• Related list behaviour

 

Tab

• Set tab visibility

 

Other

• Workflow action
• Custom button visibility
• Custom JS

 

Step 6: Drag Steps Into “When Conditions Are Met”

 

1. Drag the required step into Steps when conditions are met.
2. Configure it once it lands in the step area.

Common Example: Show/Hide a Field

• Drag Set field visibility
• Choose the field
• Set to Visible (when met)

Then add the opposite step in the “not met” section.

Step 7: Add Steps Into “When Conditions Are Not Met”

 

This is the “otherwise” behaviour.

Example:

• Drag Set field visibility
• Choose the same field
• Set to Hidden (when not met)

This avoids scenarios where a field stays visible because a user changed an earlier answer.

 

Step 8: Choose Rule Execution Behaviour

 

On the right-hand Properties panel you’ll typically see execution options such as:

• Continuous (runs as the user interacts with the form)
• Run once (runs a single time)

Recommended

• Use Continuous for visibility/required-field logic.
• Use Run once only when you are setting values or doing something that shouldn’t re-trigger repeatedly.

 

 

Step 9: Save and Test

 

1. Select Save
2. Open the form and test:
   • New item
   • Edit existing item (if applicable)
   • Different combinations of values

Testing Checklist

• Do fields appear/disappear correctly?
• Does required validation behave as expected?
• Do you ever end up in a state where a hidden field is still required?
• Are sections/tabs behaving correctly?

 

Three Practical Logic Examples (Copy Patterns)

Example A: Show a Section Based on a Choice

Goal: Show “Project Details” only when Request Type = Project

1. Create rule: Show Project Details for Project requests
2. Condition:
   • Field Value Check: Request Type equals Project
3. Steps when met:
   • Set section visibility: Project Details → Visible
4. Steps when not met:
   • Set section visibility: Project Details → Hidden

Example B: Make a Field Required When Another Field Has a Value

Goal: Make “Cost Code” required when Department = Finance

1. Create rule: Require Cost Code for Finance
2. Condition:
   • Field Value Check: Department equals Finance
3. Steps when met:
   • Set field state: Cost Code → Required
4. Steps when not met:
   • Set field state: Cost Code → Optional (or not required)

Example C: Display a Custom Error Message

Goal: Warn users if End Date is earlier than Start Date

1. Create rule: Validate dates
2. Condition:
   • Field Value Check: End Date is less than Start Date
3. Steps when met:
   • Set custom error for field: End Date → “End Date must be on or after the Start Date.”
4. Steps when not met:
   • Clear custom error (if available) or set to blank/none

Logic Best Practices

• Keep rules small and focused (one purpose per rule)
• Always define both met and not met behaviour for visibility and required states
• Name rules consistently
• Build layout first, then logic
• Test in both New and Edit modes

 

What’s Next?➡️ Next article: Sintel Apps Designer – Workflow Tab (Overview)
We’ll build a basic workflow with statuses and actions, then cover audiences, quorum, and notifications.

 

Was this article helpful?

0 out of 5 stars

5 Stars		0%
4 Stars		0%
3 Stars		0%
2 Stars		0%
1 Stars		0%

5 Submit

Please Share Your Feedback

How Can We Improve This Article?

Name

Email

Submit