Workflow is a feature by Zluri that enables IT administrators to automate their SaaS operations. Zluri currently offers two types of workflows.

1. Onboarding workflows - You can use Onboarding workflows to Add a user, Assign license to a User, Add user to different groups for different applications when a new user is added to your organization. You can do all this directly from Zluri.

2. Offboarding workflows - You can use Offboarding workflows to Remove a user, Remove license from a User, Remove user from different groups for different applications when a user is leaving your organization. You can do all this directly from Zluri.

The onboarding workflow contains 3 tabs. 

1. Draft: It lists the workflows which are not completely set up.

2. Templates: You can set up a workflow & save it as a template to run later.

3. Completed: This tab lists the completed workflows.

Creating & running an onboarding workflow:

Please follow the below steps to create & run an onboarding workflow.

Click ‘New workflow’ to create workflow.

Select the users to onboard.

Select the application for which you want to run the workflow & add the actions. 

So what are Recommended Applications and Recommended Actions?

While setting up a workflow for a user, Zluri provides you with a set of recommended applications for the user. This is typically done on the basis of commonly used apps by your organization. 

Each such application again comes with a set of recommended actions you should take for each app while onboarding. The recommended actions for each app are decided by Zluri based on the tag i.e. Onboarding/ Offboarding/Others on the workflow action.

The recommended apps for each user while onboarding are populated based on looking at the top apps used by other users in the organization with the same designation and department. This set of recommended applications can act as a checklist for you.

Once you completely set up the actions you can either save it as a template or run the workflow. 

You can save a workflow as a template. If all the actions are completely set up and the template is ready to be used, it is saved as a “Published” Playbook, which just means it is ready to be used. If all actions are not set up and there are still errors in the workflow, the template gets saved with an “Unpublished” Playbook tag, which means the playbook is not ready to be used yet. Move to the next section for more about Playbooks.

To run the workflow, Please click on the ‘Run’ button at the top right corner. It will prompt you to type ‘CONFIRM’ on the text box. Please type ‘CONFIRM’ & click ‘Run workflow.

NOTE: A workflow can only be run after all the actions in the workflow are completely set up.

You can use the Overview section to create a new workflow or use an existing playbook. The following categories are available in the Onboarding section of the Workflow module to provide information on current workflows and existing playbooks, user information and activity logs, etc:

This section provides the list of onboarding workflows currently in progress. You can click on the View All button to view the complete list of Workflows currently under process.

You can apply various filters on your workflow run logs screen to view specific workflows you want to track : 

You can also view the activity log by clicking on the app name or the View log button next to each app. This will take you to the activity log for the particular workflow execution, where you can view the run log and raw log of each playbook of the workflow. You will also find the necessary actions you should take as the next steps for failed actions. 

A Playbook is a Template of rules/actions performed by a workflow, i.e. add a user, give access to the user etc. The playbooks tab displays the list of all playbooks currently being saved by your organization in the Zluri Dashboard. Playbooks come with two tags : 

1. Published - All actions are set up, and the Playbook is ready to be used.

2. Setup Required - All actions are not set up, and the playbook can’t be used. 

In the playbook list, you can perform the following actions:

Summary of Playbook: You can view the summary of the playbook - All apps and actions in the Playbook by clicking on it; this can be useful if you just want to check if everything is ready and set up and ready to be used.

Edit playbook: You can use the edit playbook button for Playbooks with the “Setup Required” tag. These playbooks can only be edited and not be used just yet. Then, you can create or edit actions under each playbook.

Run a Playbook: You can use a Published playbook by clicking on the Run a Playbook button for the playbook and selecting users, and following the prompt to run the Playbook.

Delete Playbook: You can delete an existing playbook by clicking on the Three dots and afterwards by clicking on “Delete Playbook”.

This category lists the apps that have been recently edited and show all the relevant details, like user information. Click on the Edit option next to an app, and it will take you to the Edit section, where you can add or delete the particular draft of the playbook.

Clicking on the View all button on the top right will take you to the Drafts tab where you can also access individual draft edit menus.

The onboarding section has five tabs in total. They are: 

• Overview

• Drafts

• Playbooks

• Recent runs

• Automation rules

We have already accessed the first three from the Overview tab. Now let us have a look at the remaining 2.

This tab displays the list of recently run playbooks. You can filter the information available in the list by clicking on the Filter button and applying one or multiple filters:

You can also click on the View log button as previously demonstrated to view the playbook log details.

You can perform the following actions in the Log section:

• View the Error/Success message for each action

• Retry action for failed 

• Convert to manual task

• Retry all failed

• View the raw log to view the detailed action report.

• Export log

This section allows you to create rules for your playbook and view the existing set of automation rules and relevant information. To set a new rule, click on the New Rule button on the top right of the screen.

The onboarding rule creation screen opens.

You can set the following parameters for the rule:

1. Add trigger: Define a trigger that runs your automation. There are mainly three kinds of triggers:

• User Status Changes

• New User Added/Discovered In Zluri

• The user Is Marked For Onboarding

2. Add attributes: This enables you to selectively run the automation based on the conditions that can be set from the list below:

• Reporting Manager: This is usually the name of the employee’s reporting manager.

• User Designation: The name of the designation that applies to the user.

• Last Active: This usually is in numeric format and denotes the timestamp of the user's last activity.

• User Account Type: Usually, in text, this denotes whether the user account is an admin account or any other type.

• Critical Apps Used: The number of critical apps the user uses is an attribute here.

• Primary Source: The name of the app/apps used as the primary source for creating the condition.

• User Department: The name of the user department.

• Role: This is the name of the user role.

• Created At: a number denoting the timestamp to be used as a condition.

• Risk Level: A number denoting the risk level associated with the particular condition.

• Apps Used: The number of apps used to set the particular condition.

• User Status: a text denoting the current user status based on which the condition can be set.

3. Add a playbook: Choose to run an existing playbook for the new rule.

4. Add Delay: This is used to set a time delay after which the rule will be executed. Delays can be really helpful when working with multiple automation rules, as you might want to cascade automation rules. 

(For example, you may create an automation rule for providing access to general apps used across an organization when a New user is Onboarded, and this will run automatically immediately as soon as Zluri detects a new User marked for onboarding. 

For convenience, you can set the admin access time with a delay of 2 days after a New user is marked for onboarding. Then this automation rule can  give access to specific apps used by department users.)

5. Save rule: You can save the rule once all the previous conditions have been set.

From the list of rules available, you can perform the following actions:

1. Edit/Delete a rule by clicking on the 3-dot option next to each rule.

2. You can change the status of a rule and set it to active/inactive by clicking on the toggle below the status column.

You can manually drag each rule by the arrow next to the rule name to put it above/below a rule. This will help you set the Order of the rule.

The offboarding workflow also contains three tabs. 

1. Draft

2. Templates

3. Completed

You can follow the same process to create & run an offboarding workflow as we do for an onboarding workflow, i.e. click on New workflow and select users to set up. 

You will see that all apps are already populated with actions set up for a particular user; Zluri uses its discovery capability to discover all the apps that the user had used being part of your organization and sets up all actions to offboard a user from all these apps. 

You can use the Overview section to create a new workflow or use an existing playbook. The following categories are available in the Offboarding section of the Workflow module to provide information on current workflows and existing playbooks, user information and activity logs, etc:

This section provides the list of offboarding workflows currently in progress. You can click on the View all button to view the complete list of Workflows currently under process.

You can also view the activity log by clicking on the app name or the View log button next to each app. This will take you to the activity log for the particular app playbook where you can view the run log and raw log of each playbook of the workflow.

An offboarding Playbook is a template of rules/actions that are performed by a workflow i.e Remove a user, Remove access to a user etc. This tab displays the list of all playbooks currently being saved by your organization in the Zluri Dashboard. There are two types of offboarding playbooks onboarding playbooks : 

1. Published - Play Books which are completely set up i.e. all actions are set up, and the playbook is ready to be used. 

2. Setup Required - Playbooks which are not completely set up, and the playbook is not ready to be used yet.

In the playbook list, you can perform the following actions:

Summary of Playbook: You can view the summary of a playbook i.e. all the apps and the actions which are included in the playbook by clicking on a Playbook. This can be really useful and good practice to have a last look at a playbook before using it to check if all your requirements are covered in the playbook.

Run a playbook: You can use an existing playbook to offboard users from your SaaS apps directly from Zluri. Simply click on the Run Playbook button. Note that you can only run Published Playbooks.

Edit playbook: You can use the Edit playbook option for Setup Required Playbooks or use the Edit playbook option after clicking a Published playbook to move to edit mode. Here you can create or edit actions under each playbook.

Delete Playbook: You can delete an existing playbook from the edit playbook menu by clicking on the three dots on the top right corner of the playbook.

Recently Edited

This category lists the apps that have been recently edited and shows all the relevant details like user information. Click on the Edit option next to an app and it will take you to the Edit section where you can add or delete the particular draft of the playbook.

Clicking on the View all button on the top right will take you to the Drafts tab where you can also access individual draft edit menus.

The onboarding section has five tabs in total. They are: 

• Overview

• Drafts

• Playbooks

• Recent runs

• Automation rules

We have already accessed the first three from the Overview tab. Now let us have a look at the remaining 2.

This tab displays the list of recently run playbooks. You can filter the information available in the list by clicking on the Filter button and applying one or multiple filters:

You can also click on the View log button as previously demonstrated to view the playbook log details.

You can perform the following actions in the Log section:

• View the Error/Success message for each action

• Retry action for failed 

• Convert to manual task

• Retry all failed

• View the raw log to view the detailed action report.

• Export log

This section allows you to create rules for your playbook as well as view the existing set of automation rules and relevant information. To set a new rule, just click on the New Rule button on the top right of the screen.

The onboarding rule creation screen opens.

You canset the following parameters for the rule:

1. Add trigger: Define a trigger that runs your automation. There are mainly three kinds of triggers:

• User Status Changes

• New User Added/Discovered In Zluri

• The user Is Marked For Onboarding

2. Add attributes: This enables you to selectively run the automation based on the conditions that can be set from the list below:

• Reporting Manager

• User Designation

• Last Active

• User Account Type

• Critical Apps Used

• Primary Source

• User Department

• Role

• Created At

• Risk Level

• Apps Used

• Usage

• User Status

3. Add a playbook: Choose to run an existing playbook every time the rule is triggered.

4. Add Delay: This is used to set a time delay after which the rule will be executed.

5. Save rule: You can save the rule once all the previous conditions have been set.

From the list of rules available, you can perform the following actions:

1. Edit/Delete a rule by clicking on the 3-dot option next to each rule.

2. You can change the status of a rule and set it to active/inactive by clicking on the toggle below the status column.

        You can manually drag each rule by the arrow located next to the rule name to put it above/below a             rule. This will help you set the Order of the rule.

This action helps users make an HTTP request to an external service and send a configured callback request, using which we’ll mark the action as completed or failed on Zluri’s end. This action can be used for cases where users would like to trigger a workflow in a third-party application and mark the action as completed in Zluri once the workflow has completed in the third-party application.

The action has two steps:

Step 1 - Configuring the HTTP request

• Adding the webhook URL that needs to be called along with the type of request (GET, POST, PUT, etc.)

• Configuring the headers and parameters that need to be sent in the request body

• For the HTTP request with callback action, Zluri will also send the zluri_execution_id for that action along with the configured parameters. 

Step 2 - Configuring the callback URL for that action in the external application or service

• A callback URL unique to that specific action is automatically generated from Zluri’s end that can be configured on the end application or service that the HTTP request is made to. You can copy the callback URL from Zluri’s UI to the external service that you want to make the HTTP request to

  • The callback URL is expected to be a POST request with the format being  - 
    https://api-ext.zluri.com/ext/workflows/callback/action/action_id?zluri_execution_id={{zluri_execution_id}}
    
    

• Zluri expects the “status” to be sent in the body of the callback request - Accepted values for the status field are “completed” and “failed”. 
  
  

• Zluri expects the “zluri_execution_id” to be sent as a parameter in the callback request - This value will be auto-generated when the action is triggered from Zluri and sent as a parameter in the body of the HTTP request.
  
  

• Zluri will also require an “api_key” or “api-key” to be sent in the headers for authentication when making the callback request. You can contact your Zluri support representative to get the value of the API key for your organization.
  

Once this action is configured on both Zluri and the external application or service, if you’d like to test the callback request, you can make a test call to Zluri using the callback URL generated on the UI along with the status, the api_key, and a zluri_execution_id value of 11111111. If you receive a “200 OK” response when making the test call, that indicates that the test call is successful.

If the action has failed from Zluri’s end or the callback request is configured incorrectly, you can check the error or work with Zluri support to resolve any errors from Zluri’s end and retry. On successful completion of the action, Zluri will change the status of the action from “failed” or “pending” to “completed” on Zluri’s logs. 

Introduction

Zluri’s Zero Touch Offboarding is a streamlined process designed to automate the offboarding of employees seamlessly, eliminating the need for manual intervention. This is achieved by leveraging third-party integrations with popular HR platforms such as BambooHR, Hibob, PersonioHR, and Freshteam.

Key Features

Integration with Third-Party HR Platforms

Zluri integrates effortlessly with leading HR platforms:

• BambooHR

• HiBob

• PersonioHR

• Freshteam

This integration allows Zluri to directly retrieve essential employee information, including termination dates and other relevant details.

Automated Offboarding Rules

The Zero Touch Offboarding process operates on a set of automated rules and triggers configured within the Zluri platform. These rules are activated by events such as updates to an employee's termination date in the HR platform, prompting Zluri to initiate predefined actions to facilitate offboarding.

Customizable Actions

Organizations can tailor the actions performed during the offboarding process to meet their specific needs. Possible actions include:

• Sending offboarding emails

• Assigning tasks to team members

• De-provisioning access to necessary tools and resources

Efficient Data Retrieval

Zero Touch Offboarding ensures the efficient retrieval of employee data from the HR platform. It periodically updates information, allowing organizations to remain current with employee changes and seamlessly incorporate them into the offboarding workflow.

User-Friendly Interface

Zluri features a user-friendly interface for configuring offboarding rules and monitoring the process. Administrators can easily set up and manage automation rules, track progress, and generate reports to gain insights into the efficiency of the offboarding workflow.

Benefits

• Time and Cost Savings: Automating repetitive tasks reduces the time and costs associated with the employee offboarding process.

• Improved Offboarding Experience: The automated nature guarantees a seamless and consistent offboarding experience for IT teams, HR teams, and Application Admins.

• Enhanced Compliance and Security: Helps organizations maintain compliance with regulatory requirements and internal policies.

• Scalability and Flexibility: Highly scalable and adaptable to organizations of all sizes and industries.

How-to

This section provides detailed instructions on setting up and configuring Zluri’s Zero Touch Offboarding for your organization.

Prerequisites

Before setting up Zero Touch Offboarding, ensure you have:

• Access to the admin or appropriate permissions in the third-party application (e.g., BambooHR).

• Access to Zluri's automation rules section.

• Knowledge of the ‘termination date’ field in the third-party application.

• Instance name shared with Zluri for data retrieval.

Setup Instructions

Follow these step-by-step instructions to set up Zero Touch Offboarding:

1. Access Application Settings

   • Log in to your third-party application (e.g., BambooHR) as an admin or a user with appropriate permissions.

   • Navigate to the settings section and access the fields related to employee information.

2. Locate the ‘Termination Date’ Field

   • Identify the specific field that contains the termination date of employees, as this information is crucial for the offboarding process.

3. Share Details with Zluri

   • Provide Zluri with the instance name from which the employee's offboarding information needs to be fetched to ensure accurate data retrieval.

   • Share the details of the “termination date.” Zluri will perform the internal configuration needed to set up Zero Touch Offboarding for you.

4. Access Zluri's Automation Rules

   • Log in to Zluri and navigate to the Automation Rules section to configure rules and triggers based on various events.

5. Create a New Automation Rule

   • Within Zluri's Offboarding automation rules section, create a new rule specifically for the offboarding process.

6. Choose the Trigger

   • Select "User is Marked for Offboarding" as the trigger for the automation rule. This ensures that the rule executes whenever an employee's termination date is updated in the third-party application.

7. Choose the Condition

   • Select "User Account Type equals Employee." This condition is mandatory.

8. Configure Actions

   • Define the actions to be performed when the termination date is updated in a playbook. Actions may include sending automated farewell emails, assigning tasks to team members, or initiating an offboarding playbook. Choose the playbook to run when the automation rule triggers.

9. Deploy the Automation Rule

   • Save the automation rule and activate it for the live environment. Zluri will now use the termination date from the third-party application as a marker for offboarding.

Additional Notes

• Ensure that the termination date in the third-party application is at least two days in the future for Zluri to fetch information, which occurs every 24-48 hours.

• All users' termination dates will be fetched from the application, with the timezone defaulting to 00:00:00 GMT+0000 (UTC).

• This process will only execute for the instance shared with Zluri. If multiple instances of HRMS are integrated with Zluri, the configuration will be done on the instance level, not at the integration level. Thus, if needed, configuration should be done on all instances.

Introduction

Zluri Zero Touch Onboarding offers a streamlined process that automates employee onboarding, eliminating the need for manual intervention. By leveraging integrations with popular HR platforms like BambooHR, HiBob, PersonioHR, and Freshteam, organizations can ensure a seamless onboarding experience.

Key Features

Integration with Third-Party HR Platforms

Zluri integrates effortlessly with leading HR platforms, enabling the retrieval of essential employee information, such as hire dates, employee details, and other relevant data, directly from these systems.

Automated Onboarding Rules

The Zero Touch Onboarding process operates on a set of automated rules and triggers configured within the Zluri platform. These rules activate based on specific events, such as updates to an employee's hire date, prompting Zluri to initiate predefined onboarding actions.

Customizable Actions

Organizations can tailor the onboarding actions to meet their unique needs. This may include sending welcome emails, assigning tasks to team members, and provisioning access to necessary tools and resources.

Efficient Data Retrieval

Zluri ensures efficient data retrieval from HR platforms, periodically updating employee information to keep the onboarding workflow current and accurate.

User-Friendly Interface

The platform features an intuitive interface that allows administrators to configure onboarding rules, monitor progress, and generate insightful reports about the onboarding process.

Benefits

• Time and Cost Savings: Automating repetitive tasks reduces the time and costs associated with onboarding.

• Improved Onboarding Experience: The automation provides a consistent and seamless experience for new hires.

• Enhanced Compliance and Security: Helps maintain compliance with regulatory requirements and internal policies.

• Scalability and Flexibility: Adaptable to organizations of all sizes and industries.

How-to

This section outlines the steps to set up and configure Zluri Zero Touch Onboarding for your organization.

Prerequisites

Before beginning the setup, ensure you have:

• Admin access or appropriate permissions in the third-party application (e.g., BambooHR).

• Access to Zluri's automation rules section.

• Knowledge of the 'Hire Date' field in the HR platform.

• The instance name shared with Zluri for data retrieval.

Setup Instructions

1. Access Application Settings
   Log in to your HR application (e.g., BambooHR) as an admin or user with the necessary permissions. Navigate to the settings section to access employee information fields.

2. Locate the ‘Hire Date’ Field
   Identify the field that contains employees' hire dates, which is crucial for onboarding.

3. Share Details with Zluri
   Provide Zluri with the instance name and hire date details to ensure accurate data retrieval. Zluri will handle the internal configuration for Zero Touch Onboarding.

4. Access Zluri's Automation Rules
   Log in to Zluri and go to the Automation Rules section to set up rules and triggers based on various events.

5. Create a New Automation Rule
   In the onboarding automation rules section, create a new rule specifically for onboarding.

6. Choose the Trigger
   Select "User is Marked for Onboarding" as the trigger to execute the rule whenever an employee's hire date is updated.

7. Choose the Condition
   Set the condition to "User Account Type equals Employee." This condition is mandatory.

8. Configure Actions
   Define the actions to be taken when the hire date is updated. This may include sending welcome emails, assigning tasks, or initiating an onboarding playbook.

9. Deploy the Automation Rule
   Save and activate the automation rule for the live environment. Zluri will now utilize the hire date from the HR application as a marker for onboarding.

Additional Notes

• Ensure that the hire date in the HR application is set at least two days in the future for Zluri to fetch information, which occurs every 24-48 hours.

• All users' hire dates will be retrieved from the application, defaulting to the timezone of 00:00:00 GMT+0000 (UTC).

• The process will execute only for the instance shared with Zluri. If multiple HRMS instances are integrated, configurations must be done at the instance level.

App requisition automation rules

Admins will be able to set up multiple automation rules to apply for different license approval processes followed within the organization. 

These rules can be set up in a way where different request conditions will trigger a different approval workflow

For instance, if an organization follows a different workflow for each department, different rules can be set up for each department such that it goes through a different approval process. Or if there’s a different approval process for apps that are already managed by the organization and apps that need to be newly procured, a different approval process can be set up

Automation rules allows you to do this using two important components - ability to set up conditions for each rule, and configuring different approvers for each rule

Each rule can have two sets of conditions - check whether the application is already used by the org or not, and more specific criteria such as the requester’s department, designation, reporting manager, or the specific application requested. This helps create very specific approval workflows that apply to each request that’s raised

Each rule can also have its own set of approvers that will need to take an approval action for every request that fits the conditions of that rule. For example - a request raised by a member of the sales team can have the most relevant members approve that request, say the employee’s reporting manager, the head of sales, and then the IT admin 

In the overview section of any particular app, Zluri provides the employee to request a particular license or an app. This request by the employee involves specific steps, which are explained further in the doc.

1. Step 1: The employee must fill out the application and license tier names. The cost/Licence/term is pre-typed based on the data of 225k applications of Zluri’s library. The employee can change the cost as per the current needs. 

2. Step 2: Zluri prompts similar applications with optimal license costs when the user clicks on the continue button. The user can choose to go for the recommended apps or ignore the recommendations and continue with the request process. 

3. Step 3: A page containing the detailed version of the request is generated where the employee has to describe the need for the request. The employee must also upload the necessary documents to justify his/her needs. 

The employee dashboard has a provision to view all the requests, including license requests and app requests. 

This page contains all the basic details. This view provision also displays the status of the request helping the employees in keeping track of all the requests. The employee can also add new requests from this page which is proof of a seamless UI experience. 

The visualizations help them better comprehend their application usage.  

After the requesting process, Zluri offers a 3-level hierarchy of approval. Application managers, Reporting managers, and IT admins. 

In this approval process, the power to override the approval or rejection decision depends on the authority level. The higher authority can override the decision taken by the lower admins or the managers.  

The admins also add comments explaining why the request was rejected. 

In an ideal approval situation, only the assigned approval authority approves the request. However, Admins have the authority to approve a request on behalf of an approver at each stage of the approval process.

Whenever the approval status is pending a particular approval, the admin can approve, reject or notify the approver.

Approve on behalf of an approver -

1. If approver one is pending, and admin approves

   1. Admin gets added as a new approver after approver 1, and the status will be “Approved on behalf of approver 1.”

   2. Approval update and action required notifications for approver 2, admins, and requestee will get triggered accordingly.

2. The same logic holds for the rest of the approvers.

1. If approver one is pending, and admin rejects it -

   1. Admin gets added as a new approver, and status will be “Rejected on behalf of approver 1.”

   2. Rejection notifications for other approvers, requestee, and admins will be triggered.

   3. The request's status changes to “rejected” on the “All Requests” page.

2. Any stage of rejection will reject the complete request process.

Admins have the right to override the rejected request from any of the rejection stages. Admin will see the option to override rejection, and once they reject, “approval update” and “action required” notifications for the next approver, admins, and requestee will be sent.

In the process, there is also an option to add new approvers among the default approvers list. The names can be searched within the organization, and the selected approver can be dragged and placed anywhere among the list of approvers.

Once done, the notifications are sent to all the stakeholders assigned.

We have an option to add approvers based on roles as well. It can be configured in the “automation rules” section of the workflows. In the approver summary, “roles or approver” can be added by selecting the required role/approver from the dropdown.

Notes should be added that admins will be notified to add approvers in case of role unavailability. Saving it triggers the rule which will be reflected on the “request summary” page.

Onboarding actions  -

Similarly to adding roles and approvers, different approval actions can be added too. In the automation rules section of the workflows, approval action can be added. As an action, the option to “run playbook” can be selected. The configuration can then be done based on what playbook to run, what should be the delay and the mail selection in case of failure.

Offboarding actions  -

The offboarding playbook can be run similarly. The “Run offboarding playbook” option is selected in the “Add action” menu bar, to which the delay and reminder can be added accordingly. Once done, the rule can be saved and triggered automatically.

The employee must keep track of the changes happening in this process. Hence Zluri introduces a change catalogue. 

The employee can see all the updates on the request made. 

The approval and rejection from the higher admins, the change in the duration of the basic detail of the license, and the comments added by the admins are all displayed so that the employee is always kept updated on the request's status. 

Once an employee requests an application or a license, the request is then sent to the approver for their approval. The requests are all in one place for approval.