Record Rules are automation tied to specific form components that execute when that particular form is submitted. Unlike table rules (which run for all data entry methods), record rules only run for their specific form, giving you granular control over automation for different user workflows.

Record rules are perfect for form-specific logic, auto-populating fields based on user input, and implementing different automation for different forms that work with the same data table.

Understanding when to use each is crucial:

When you have multiple forms for the same table with different requirements:

• Customer Portal Form - Creates tickets with status "New" and priority "Medium"
• Internal Support Form - Creates tickets with status "In Progress" and assigns to logged-in agent
• Manager Override Form - Creates tickets with any status and priority

Automation that depends on form context or workflow:

• New customer form creates welcome tasks and sends onboarding emails
• Quick-add form uses minimal automation for speed
• Full registration form includes extensive validation and related record creation

Using values entered in the form to populate other fields:

• Copy billing address to shipping address
• Calculate totals from line items
• Pull related data from connected records

Form submissions that trigger multi-step processes:

• New project form creates default tasks and milestones
• Event registration form creates attendee record and sends confirmation
• Order form creates line items and updates inventory

1. Go to Page Builder
2. Select the page with your form
3. Click on the Form Component to edit it
4. Click the Rules tab in the component settings
5. Select Record Rules from the left sidebar
6. Click Add New Record Rule

Select what the rule should do:

• Update This Record - Modify the record being submitted
• Update Connected Record - Modify a related record
• Insert Connected Record - Create a new related record
• Insert New Record - Create a record in any table

Define when the action should execute:

• Based on form field values
• Based on connected record data
• Based on logged-in user properties
• Or always run (no conditions)

Specify values using:

• Custom Value - Static value
• Set Blank - Clear the field
• Form Value - Copy from another form field
• Connected Value - Pull from related record
• Logged-in User Field - Use current user data
• Auto Logged User - Link to current user
• Current Date/Time - Timestamp

1. Click Save to save the rule
2. Submit the form to test
3. Verify the rule executes correctly
4. Check that conditions work as expected

Modifies fields in the record being submitted. This is the most common record rule action.

Scenario: When a note is created via a form, automatically set the "Date Created" to the current date and "Created By" to the logged-in user, even though these fields aren't on the form.

Configuration:

• Form: Add Note Form
• Action: Update This Record
• Conditions: Always (no conditions)
• Field Values:
  • Date Created → Current Date/Time
  • Created By → Auto Logged User

This is a Record Rule (not a Table Rule) if you want this to happen only when notes are created through this specific form, but not when created through API or other forms.

Scenario: When an order is created with a total over $1,000, automatically set the status to "Requires Approval". Orders under $1,000 get status "Processing".

Configuration (Two Rules):

• Rule 1 - High Value Orders:
  • Action: Update This Record
  • Condition: Total is greater than or equal to $1,000
  • Field: Status → Custom Value: "Requires Approval"
• Rule 2 - Standard Orders:
  • Action: Update This Record
  • Condition: Total is less than $1,000
  • Field: Status → Custom Value: "Processing"

Scenario: When a user checks "Billing address same as shipping address", automatically copy all shipping address fields to billing address fields.

Configuration:

• Action: Update This Record
• Condition: "Same Address" checkbox equals Yes
• Field Values:
  • Billing Street → Form Value: Shipping Street
  • Billing City → Form Value: Shipping City
  • Billing State → Form Value: Shipping State
  • Billing Zip → Form Value: Shipping Zip

Note: Record rules always override form values. Even if the user enters something in the billing fields, the rule will overwrite them if the condition is met.

Scenario: When creating a task assigned to a project, automatically set the task's priority and department based on the selected project's values.

Configuration:

• Form: Add Task Form
• Action: Update This Record
• Conditions: Project is not empty
• Field Values:
  • Task Priority → Connected Value: Project Priority
  • Department → Connected Value: Project Department
  • Due Date → Connected Value: Project Due Date

Modifies related records in connected tables when the form is submitted.

Scenario: When a task is created or edited via a form, update the parent project's "Last Activity" field to track recent activity.

Configuration:

• Form: Task Form (add/edit)
• Action: Update Connected Record (Project)
• Conditions: Always
• Field Values:
  • Last Activity → Current Date/Time
  • Last Updated By → Auto Logged User

Scenario: When a support ticket is submitted by a customer, increment the customer's "Total Tickets" counter and update their "Last Contact Date".

Configuration:

• Form: Submit Ticket Form
• Action: Update Connected Record (Customer)
• Conditions: Always
• Field Values:
  • Last Contact Date → Current Date/Time
  • Status → Custom Value: "Active"

Note: For counting, it's better to use equation fields that count connected records automatically.

Creates a new related record in a connected table when the form is submitted. This is one of the most powerful record rule actions.

Scenario: When a new project is created via the "New Project" form, automatically create three initial tasks: "Kickoff Meeting", "Requirements Gathering", and "Project Planning".

Configuration (Three Rules):

• Rule 1 - Kickoff Task:
  • Form: New Project Form
  • Action: Insert Connected Record (Task)
  • Conditions: Always
  • Field Values:
    • Task Name → Custom Value: "Kickoff Meeting"
    • Status → Custom Value: "Not Started"
    • Priority → Form Value: Project Priority
    • Assigned To → Form Value: Project Manager
• Rule 2 - Requirements Task: Similar for "Requirements Gathering"
• Rule 3 - Planning Task: Similar for "Project Planning"

Scenario: When a new client is added with "VIP" status, automatically create a welcome task for the account manager. Regular clients don't get this task.

Configuration:

• Form: Add Client Form
• Action: Insert Connected Record (Task)
• Conditions: Client Type equals "VIP"
• Field Values:
  • Task Name → Custom Value: "VIP Client Welcome Call"
  • Description → Custom Value: "Schedule welcome call with new VIP client"
  • Assigned To → Custom Value: Account Manager
  • Due Date → Custom Value: 3 days from now
  • Priority → Custom Value: "High"

Scenario: When someone registers for an event, create an attendee record linked to both the event and the registrant.

Configuration:

• Form: Event Registration Form
• Action: Insert Connected Record (Attendee)
• Conditions: Always
• Field Values:
  • Event → Connected Value: Selected Event
  • Attendee Name → Form Value: Your Name
  • Email → Form Value: Your Email
  • Registration Date → Current Date/Time
  • Status → Custom Value: "Registered"
  • Confirmation Sent → Custom Value: "No"

Creates a new record in any table (not necessarily connected). Best for logging, audit trails, and creating records that should persist even if the original record is deleted.

Scenario: When a client record is created, log the activity in an Activity Log table for audit purposes.

Configuration:

• Form: Add Client Form
• Action: Insert New Record (Activity Log table)
• Conditions: Always
• Field Values:
  • Activity Type → Custom Value: "Client Created"
  • Client Name → Form Value: Client Name
  • Performed By → Logged-in User's Name
  • Timestamp → Current Date/Time
  • Details → Custom Value: "New client record created"

Important: Use regular fields (not connection fields) in the Activity Log so the log entry persists even if the client record is later deleted.

Scenario: When a high-priority support ticket is submitted, create a notification record for the support team.

Configuration:

• Form: Submit Ticket Form
• Action: Insert New Record (Notifications table)
• Conditions: Priority equals "High" OR Priority equals "Critical"
• Field Values:
  • Notification Type → Custom Value: "High Priority Ticket"
  • Message → Custom Value: "New high-priority ticket requires attention"
  • Ticket Number → Form Value: Ticket Number
  • Created Date → Current Date/Time
  • Status → Custom Value: "Unread"

Record rules can access any field in the form, even hidden fields:

• Copy values from one field to another
• Use values for calculations
• Pass values to connected records
• Use in conditions to control rule execution

You can hide fields from the form but still use them in record rules:

• Hide "Created By" field but set it via record rule
• Hide "Date Created" but auto-populate it
• Hide calculated fields that are set by rules

Tip: This keeps forms clean while maintaining data integrity.

Record rules execute when the final step is submitted:

• Access fields from any step
• Use values collected across all steps
• Rules run after all validation passes

One of the key advantages of record rules is having different automation for different forms on the same table.

Purpose: Customers submit tickets externally

Record Rules:

• Set Status → "New"
• Set Priority → "Medium" (default)
• Set Source → "Customer Portal"
• Set Submitted By → Auto Logged User (customer)
• Send Email → Confirmation to customer
• Create Notification → For support team

Purpose: Support staff create tickets on behalf of customers

Record Rules:

• Set Status → "In Progress"
• Set Assigned To → Auto Logged User (support agent)
• Set Source → "Phone Call" or "Email"
• Send Email → Confirmation to customer only

Purpose: Rapid ticket creation with minimal fields

Record Rules:

• Set Status → "New"
• Set Priority → "Low"
• No emails sent (speed priority)

Record rules are ideal when:

• Different forms need different automation
• You need to use values entered in the form
• The automation is part of a specific workflow

• Table Rules: Universal logic that always applies
• Record Rules: Form-specific additions or overrides
• Record rules execute AFTER table rules
• Record rules can override table rule values

Since record rules are form-specific:

• Test each form individually
• Verify rules execute as expected
• Check for conflicts with table rules
• Ensure conditions work correctly

When you have multiple forms:

• Document what each form does differently
• Note which rules apply to which forms
• Maintain consistency where appropriate
• Use descriptive rule names

Keep it simple:

• Don't create too many rules per form
• Consolidate similar logic
• Use table rules for universal logic
• Keep record rules focused on form-specific needs

Remember the order:

1. Table rules execute first
2. Record rules execute second
3. Record rules can override table rule values
4. Multiple record rules execute in the order they appear

Requirement: When creating a project, the number and type of default tasks depend on the project type selected.

Solution: Create multiple conditional record rules:

• Software Project Tasks:
  • Condition: Project Type equals "Software Development"
  • Insert Connected Records: Requirements, Design, Development, Testing, Deployment
• Marketing Project Tasks:
  • Condition: Project Type equals "Marketing Campaign"
  • Insert Connected Records: Research, Creative Brief, Design, Copy, Launch
• Consulting Project Tasks:
  • Condition: Project Type equals "Consulting"
  • Insert Connected Records: Discovery, Analysis, Recommendations, Presentation

Requirement: Purchase requests have different approval requirements based on amount:

• Under $500 - Auto-approved
• $500-$5,000 - Manager approval required
• Over $5,000 - Manager and Director approval required

Solution: Create conditional record rules:

• Rule 1 - Auto Approve:
  • Condition: Amount is less than $500
  • Update This Record: Status → "Approved"
• Rule 2 - Manager Approval:
  • Condition: Amount is between $500 and $5,000
  • Update This Record: Status → "Pending Manager Approval"
  • Insert Connected Record: Create approval request for manager
• Rule 3 - Director Approval:
  • Condition: Amount is greater than $5,000
  • Update This Record: Status → "Pending Director Approval"
  • Insert Connected Record: Create approval requests for manager AND director

Requirement: When users register for an event, check capacity and either confirm registration or add to waitlist.

Solution: Use conditional record rules with equation fields:

• Setup: Event table has "Max Capacity" field and "Current Registrations" equation field that counts attendees
• Rule 1 - Confirm Registration:
  • Condition: Event's Current Registrations is less than Event's Max Capacity
  • Update This Record: Status → "Confirmed"
  • Insert New Record: Send confirmation email
• Rule 2 - Waitlist:
  • Condition: Event's Current Registrations is greater than or equal to Event's Max Capacity
  • Update This Record: Status → "Waitlisted"
  • Insert New Record: Send waitlist notification

Check:

• Are you testing the correct form?
• Is the rule attached to the right form component?
• Do conditions match your test data?
• Are you submitting the form (not just saving)?

Check:

• Are you using the right value type? (Form Value vs Custom Value)
• Is the source field populated?
• Are table rules overriding record rule values?
• Check the execution order (table rules run first)

Check:

• Is the connection field properly configured?
• Are you using "Insert Connected Record" (not "Insert New Record")?
• Do conditions allow the rule to execute?
• Are all required fields in the connected table being set?

Check:

• Is the field actually in the form?
• Is the field hidden or removed?
• Are you using the correct field name?
• For multi-step forms, is the field in an earlier step?

Build a complete event registration system with record rules:

1. Events Table: Event Name, Event Date, Max Capacity, Description
2. Registrations Table: Event (connection), Attendee Name, Email, Registration Date, Status

1. Create a form for the Registrations table
2. Include fields: Event, Attendee Name, Email
3. Hide fields: Registration Date, Status (will be set by rules)

1. Set Registration Date:
   • Action: Update This Record
   • Condition: Always
   • Field: Registration Date → Current Date/Time
2. Set Status to Confirmed:
   • Action: Update This Record
   • Condition: Always (simplified version)
   • Field: Status → Custom Value: "Confirmed"
3. Create Confirmation Log:
   • Action: Insert New Record (Activity Log table, if you have one)
   • Condition: Always
   • Fields: Activity Type → "Registration", Details → Form values

1. Submit the registration form
2. Verify:
   • Registration date is set to current date
   • Status is "Confirmed"
   • Activity log entry is created

Record rules provide form-specific automation:

• Attached to individual form components
• Execute only when that specific form is submitted
• Perfect for different automation for different forms
• Can access and use form field values
• Execute after table rules (can override table rule values)
• Use for auto-populating fields and creating related records