
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
What is Employee forms?
Employee forms provide an efficient means of gathering employee input without the need for creating new records or adding new fields to existing tables. These forms are typically created using a survey designer and can be utilized within HR Tasks to update employee information, such as HR Profile details.
One common requirement is the ability to update HR Tasks with input from employees.
For example, an employee may submit a question regarding their pension plan through the Employee Center Portal. The agent assigned to the case will need to review the question, but may require additional information from the employee, such as the date the employee started working.
This information can be provided through a task available in the Employee Center Portal, without the need to directly update the HR Profile (there is no need to create a field in the HR Profile to store the date the employee started working – in order to understand how many years the person was paying taxes!).
For that, we should be able to use Employee forms to update directly the HR Task, but posting a the employee feedback in the work notes.
How is this working?
When constructing an employee form, it is necessary to establish a condition that allows for the selection of a specific record from a table. For example, this is useful for identifying the correct HR profile of an employee, where the condition could be something like "user is dynamic 'me'."
However, this solution may not be suitable in cases where the user has multiple open tasks. To address this issue, I propose the following solution.
ServiceNow processes employee forms by creating a survey instance when an HR Task of type "Collect Employee Input" is set to Ready and assigned to a user. This survey instance then collects the information specified in the Employee form mappings.
When the employee submits their comment through the to-do list, the survey instance is marked as complete, triggering the execution of the business rule "Reset invoking task status" in the asmt_assessment_instance. This business rule then executes the script include "sn_hr_sp.EmployeeDataCollection" and the method "saveUpdatedData." The "saveUpdatedData" method validates the current assessment instance against the employee form record and fails if more than one record is retrieved from the employee form condition.
If only a single record is retrieved, the employee form mappings will be executed in accordance with the configuration.
How to update HR Tasks directly with Employee forms?
Now that we have an understanding of how the out-of-the-box employee forms function, it's time to consider how we would like to customize their behavior. If we desire to link the assessment instance directly to the HR task that originated it, without evaluating the conditions in the employee form, we can accomplish this by modifying the code in the "saveUpdatedData" method. In this case, I chose to create a copy of the method and made the necessary changes there. Specifically, I commented out line 312, which adds the employee form condition as an encoded query to the GlideRecord, and added the query "recordGr.addQuery("sys_id", current.sys_id)", which retrieves a record from the "tablename" (in this example, the HR task table) where the sys_id is equal to "current.sys_id" (this represents the sys_id of the HR task that is linked with the assessment instance).
By implementing this approach, I am able to ensure that only a single record will be retrieved, corresponding to a single HR task. From this point on, the code that is executed is the out-of-the-box code, which will perform the employee form mappings.
The final step is to modify the business rule "Reset invoking task status" to accommodate both employee form records with conditions and those with a direct linkage to the HR task. To achieve this, I created a new Boolean field in the employee form table, called "Map to HR Task?" and used it in the business rule to determine whether to execute the method "sn_hr_sp.EmployeeDataCollection().saveUpdatedData" or the one I created, called "sn_hr_sp.EmployeeDataCollection().saveUpdatedDataToSingleTask."
To ensure the proper execution of this customization, I validate whether the assessment instance state is "Complete" and whether the employee form record associated with the task linked to the assessment instance contains the flag "Map to HR Task?" set to true. If this is the case, the new method I created is executed; otherwise, the out-of-the-box code is executed.
Improvements to the presented approach
As you can see, this implementation is relatively straightforward and allows for the expansion of Employee forms to cover a wide range of new use cases. There are a few areas for improvement, such as:
- Instead of modifying the script "sn_hr_sp.EmployeeDataCollection" by adding a new method, it may be more appropriate to create a copy of it and make changes there. This practice can help minimize the number of skipped records during upgrades.
- To enhance the user experience, the "condition" field of the employee form could be hidden when the new field "Map to HR Task?" is set to true, as the system will not use the condition field in the employee form in this scenario.
While it may not be complex solution, it addresses a common need and can prove to be quite useful.
Please feel free to provide feedback and suggestions.
Best Regards,
Filipe Cruz
- 4,551 Views
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.