Overview

The Secure Screen Node is a specialized feature in guided workflows designed to enhance data security. It allows sensitive information, such as credit card numbers and personal identification details, to be transmitted directly to a PCI-compliant server, bypassing the Sprinklr platform entirely. This ensures that sensitive data is not stored on Sprinklr’s servers, significantly reducing the risk of unauthorized access or data breaches. This node is ideal for workflows requiring high security and compliance with privacy regulations.

​

Various Components in Secure Screen Node

Components under the Secure Screen node are divided into three groups:

1. Display Components

   • Banner

   • Description Text

2. Layouts

   • Divider

   • Three Columns

   • Two Columns

3. Input Components

   • Radio Group

   • Text Input

​

Business Use Case

Secure screens are commonly used in workflows involving sensitive operations, such as Payment Card Processing (PCP) or handling confidential customer information. By preventing data storage and ensuring direct transmission to secure servers, secure screens help maintain trust and comply with stringent security standards, providing a safe and reliable customer experience.

​

Various Fields Under Screen Properties of Secure Screen Node

• Title Bar Text: Specifies the text displayed in the title bar of the secure screen.

• Screen Name: Assigns a unique identifier to the secure screen for easier management.

• Description: Provides additional details or context about the secure screen's purpose.

• Disable Auto Complete for Form Fields: If this checkbox is enabled, it prevents the browser from suggesting previously entered values in form fields during guided workflow execution.

• Disable Auto Fill of Personal Information: If this checkbox is enabled, it prevents the browser from automatically filling in saved personal details like name, email, or address in form fields.

• Auto Submit Screen: Automatically submits the screen or navigates to the next one without agent input, reducing manual clicks. When enabled, the Delay Before Submitting (in seconds) field also appears:

  • Delay Before Submitting (in seconds): You can specify the time (in seconds) to wait before auto-submitting the screen.

• Advanced Screen Layout Settings: If you enable this toggle, you will see the following options:

  • Layout: You can define the screen structure; currently, only the One Page Layout is supported.

  • Spacing (in px): You can set the spacing between components in pixels.

  • Height: You can choose between Full height or Auto Fit based on content.

  • Vertical Alignment: Align screen content to Start, Center, or End vertically.

• Enable reCAPTCHA v3: Enables the selection of a reCAPTCHA v3 credential for added security. ReCAPTCHA can be added as an input component to ensure that the user completing the form or using the website is a human, not an automated bot. For more details about reCAPTCHA, refer to https://sprinklr.atlassian.net/wiki/spaces/CCAAS/pages/4643882777/reCAPTCHA?atlOrigin=eyJpIjoiZWUyMjM1ZWVkODRjNDgyZWFiZGNiMzU3ZTliZDhlMTEiLCJwIjoiYyJ9.

• Navigation Bar: If you enable this toggle, you get the following options:

  • Footer Size: Configures the size of the footer section on the screen.

  • Button 1: Defines the label and action for the first button on the screen.

  • Button 2: Defines the label and action for the second button on the screen.

• Navigation Bar: Once this toggle is enabled, you can configure the following:
  
  

  • Footer Size: You can choose from preset sizes, such as Medium or Large, to adjust the footer’s visual space.

  • Button: To add any button, you need to configure the following:
    

    
    

    • API Name:

      The

      API Name

      is a unique identifier for a specific object, field, or component. It is typically used programmatically or in backend integrations. It often follows a convention with underscores separating words (e.g., Customer_Status_ _c)

      ​

    • Label: This allows you to add a customized name to the button. From the arrow, you can also choose the icon that you want to be displayed on the button.

    • Button Action: You can define what action you want the button to perform. Available actions in the dropdown include:

      • Move to Next Screen: Navigates to the next screen in the workflow.

      • Close Screen: Closes the current screen.

      • Go Back to Previous Screen: Returns to the previous screen.

      • Send Payload: Sends a predefined payload, typically for backend processes.

      • Authentication: Triggers a user authentication flow.

    • Variant: Defines the type and visual style of the button based on its importance and purpose. The selected variant also affects the button’s icon and overall appearance. Options in the dropdown include:

      • Primary: Main action button, used for the most important action on the screen.

      • Secondary: Supporting action, used for less prominent actions.

      • Tertiary: Low-emphasis button, often used for optional or less critical actions.

      • Minimal: Bare-minimum styling, usually used when visual distraction should be minimal.

      • Link: Styled like a hyperlink, used for navigation or less formal actions.

    • Intent: Defines the purpose or context of the button action, which dynamically adjusts the button’s color. Available options in the dropdown include:

      • Default – Blue: Used for standard or neutral actions.

      • Success – Green: Indicates a successful or positive action.

      • Warning – Yellow: Signals caution or requires user attention.

      • Error – Red: Represents a critical or destructive action.

    • Position: Specifies where the button appears on the screen. Available options include:

      • Bottom Right: Places the button at the lower right corner of the screen.

      • Bottom Left: Places the button at the lower left corner of the screen.

      • Bottom Center: Centers the button at the bottom of the screen.

      • Top Right: Places the button at the upper right corner of the screen.

    • Button Disability Conditions: Defines the rule or set of conditions under which the button will be disabled. This ensures that the button can only be used when specific criteria are met, helping to prevent invalid actions and guide the user through the workflow contextually.

      • 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.

    • 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 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.