Overview

The Date and Time Field in a form is an interactive input element designed for users to select or input specific dates, times, or both. It is widely utilized for purposes such as scheduling, setting appointments, meeting deadlines, or collecting time-sensitive information, ensuring precision and efficiency in data input.

​

Various Fields in Date and Time Input

• Show Time: Selecting this checkbox will allow you to display the time within the component. 

• Show Calendar Upfront: When enabled, the calendar view is displayed as soon as the screen loads. If disabled, the component shows a collapsed field until clicked.

• Enable 24-Hour Format: This checkbox enables you to show the time in a 24-hour format.  

• Default Timezone: You can select the default time zone based on the region where you will be using this feature. 

• Include Timezones: All time zones are included by default if no specific options are selected. 

• Date & Time Format: Sprinklr offers a variety of date and time formats to help you select your preferred options. 

• Enable Date & Time Conditions: This field allows you to define specific conditions for displaying date and time values. By using a Groovy script, you can configure the display to show dates that are after, before, or within a specified time range.

• This toggle also allows you to evaluate and compare different Date & Time inputs within the same screen. Evaluating screen components using separate Decision Box or Update Properties nodes after the screen often causes redundancy and extra configuration effort. The same screen evaluation feature streamlines the process by enabling direct evaluation within the same screen, improving efficiency and reducing complexity.

  • If there are two Date & Time fields on a screen — the first Date & Time and the second Date & Time — you can ensure that the second Date & Time input is always After, Before, or Within the range of the values entered in the first Date & Time input, depending upon the required use case. For example, if the first date is set to March 26th, 12:30 PM, this feature will enforce that the second date can only be set to after, before, or within the time frame of the first Date & Time input as per the applied configuration (In the screenshot below, the After configuration is applied). This feature ensures logical and sequential data entry. This can be done through the configuration mentioned below.
    

    
    

  • Configuration:

    • For example, if you want to ensure that the values of the second Date & Time input are later than the first Date & Time input, navigate to the second Date & Time input field and click the Enable Date & Time Conditions toggle. Once enabled, you can add configuration based on the use case. To do this, select After and apply the appropriate Groovy script (mentioned below) to enforce the rule. This ensures that the date and time in the second date & time input will always be later than those in the first date & time input.

      ​

    • Groovy script example:

      return newScreen_5? newScreen_5.DATE_8:null;

      • Groovy Explanation:
        If the newScreen_5 value is not null, then the newScreen_5.DATE_8 is returned; else null value is returned.

        ​

    • The date and time input you want to control should have the Controlling Field set to the API name of the date and time input that is controlling it. For instance, in the provided example, the API Name of the first Date & Time input should be added in the Controlling Field of the second Date & Time input.

      

      ​

    • Dynamic Range (Using Variables): Dynamic Range allows you to configure the Date & Time Input component to display only specific dates or date ranges that are dynamically determined, such as through an API response or a workflow variable. The dynamic range expects a variable that contains one or more accepted ranges in epoch milliseconds (UTC). To configure this,

      • Enable Date & Time Conditions.

      • Under Within ranges, select Dynamic Range, and then select Enter Custom Code.

      • Choose a variable or API response as the source of your valid date ranges. This variable should contain the allowed dates in the following format:

        [[start1, end1], [start2, end2], ...]

        Where start and end are epoch timestamps in milliseconds (UTC) representing the beginning and end of a valid range.

        ​

      • Configuration Examples:

        Multiple Date Ranges - If you want users to select dates on:

        * 3 October 2025

        * 15–22 October 2025

        Your variable should be defined as:

        [[1759363200000, 1759449599000], // Entire day: 3 Oct 2025

        [1760400000000, 1761004800000] // 15–2 Oct 2025]

        ​

        Single Specific Date - To allow selection of only 5 October 2025, configure a single range

        [[t1, t2]]

        Where t1 and t2 are any two epoch timestamps falling within 5 October 2025.

      • Only the dates within these ranges are selectable. All other dates are greyed out.

      ​

​

• Business Hours Type: You can specify business hours in this field, which can be either static or dynamic. Selecting "static" allows you to use the business hours available in the system, while choosing "dynamic" gives you the flexibility to add resources or enter custom code. 

• Fallback Business Hours: These hours will be considered if the dynamic business hours field is found to be empty. 

  ​

  Note: The fallback Business Hours field will be relevant only for the Dynamic Business Hours.

  ​

• Enable Reporting: The "Enable Reporting" toggle allows users to specify whether the auto-drafted values in the screen component should be included in reporting. When enabled, this ensures that auto-saved data is captured and made available for analytics, addressing gaps in reporting accuracy caused by un-submitted workflows.

• Configure Error Message: This field allows you to create a warning message for users when they do not select the checkbox. 

• Add on Select Action: Enable this to pass the value selected to the next or previous screen component. Available options are:

  • Next Screen Action - Automatically moves to the next screen when the date is selected.

  • Previous Screen - Moves to the previous screen.

• Visibility Conditions: It is a rule or set of rules that determines whether a specific element, field, or component is visible to users in an application or interface. These conditions are typically based on factors such as user roles, permissions, field values, or contextual data. Visibility conditions ensure that users only see relevant information, improving usability and security. 

  • Example  

    • Condition: Display a "Priority Escalation" section if the "Ticket Priority" is set to "High."

    • Implementation: Visibility Condition: Ticket_Priority == 'High' 

    • Result: The "Priority Escalation" section appears only for high-priority tickets. 

• Input Disability Condition: It refers to a rule or set of criteria that determines whether a specific element, such as a field, button, or component, should be disabled (i.e., grayed out and non-interactive) in a user interface. It restricts user interaction based on certain conditions, ensuring that actions are contextually valid or preventing errors. 

  • Example: 

    • Based on Field Value: 

      • Condition: Disable the "Submit" button if the "Terms and Conditions" checkbox is unchecked. 

      • Result: The user cannot submit the form until they accept the terms.

    • Based on User Role: 

      • Condition: Disable the "Delete Record" button for users without "Admin" permissions. 

      • Result: Only admins can delete records, while other users see the button but cannot interact with it. 

    • Based on Data Completeness: 

      • Condition: Disable the "Next" button until all required fields are filled. 

      • Result: Users are prevented from moving forward until they complete the required steps.