Recruit update - December 2021

Over the next 2 weeks, we are rolling out our final major update of the year. This includes some of our roadmap commitments for 2021, related to supporting closer integration between the Kallidus Suite of products and the ability to switch between them, as well as single sign-on (SSO) enhancements required to support this.

Recruit and Recruit admin

Implement the Kallidus Suite global navigation
For customers who have multiple Kallidus products, this will allow users to seamlessly switch between them via a new level of global navigation at the top. This functionality requires customers to be using single sign-on (SSO) and to have other relevant Kallidus products authorised for users.

At this stage, the new global navigation will be available in Recruit only (the User portal) and not in Recruit admin (the Backoffice).

Recruit admin single sign-on (SSO)
We are now able to offer single-sign on for the Recruit admin portal (Backoffice). If SSO is set up, this means all Recruit users within your organisation are no longer required to login manually to Recruit, which could be seen by some IT departments as a security enhancement.

Customers with SSO already enabled and who have already been migrated to the new user portal and new kallidus-suite URLs will now find that the Recruit admin portal (Backoffice) will also log users in automatically, via your company SSO provider.

Note that this will mean that you can't log out of Recruit any longer, as you will be immediately logged in again.

Improvements to "Get started" user journey when single sign-on (SSO) is enabled
Where self-registration is enabled, a new user will be automatically directed to the user registration form in Recruit when they first visit the site and they will not be required to enter a password. Once the form is submitted, the user will be logged in immediately for the first time automatically.

New setting to disable manual login - option for when single sign-on (SSO) is enabled
Customers with SSO enabled may now request manual login to be disabled if required, leaving their company SSO as the only way to login to either Recruit (User portal) or Recruit admin (Backoffice). Some customers may see this as an improvement to security, as it will enforce their users to be logged in and authenticated with their own network.

Some customers, however, may still prefer to maintain the manual login option, as this will allow users to continue to use the system, even if their own SSO infrastructure fails.

New setting to disable self-registration
Self-registration allows customers to reduce admin by allowing users to self-register in the User portal as a Hiring Manager. This in turn allows them to kick off the process to request a vacancy, which then would need to be approved, before they would gain further access to their candidates, etc.

Some customers, however, prefer to have more direct control over which users are added to their system, so we now support self-registration being disabled.

Improvements to user experience for deleted users
If a user has been deleted tries to re-register or login to the user portal, they will now be made aware that they already have an account, but it has been deactivated. They will be directed to contact their HR team to request reactivation. This will also help to avoid issues around users creating duplicate accounts, etc.

Improvement to management of user preferences with pre-selected options
Currently, in systems with configuration to create user preferences with pre-selected options, the pre-selections are only populated when a new user is created. This means that if a preference of this type is added after a user is created or if the selected options change, existing users would not get updated.

In most cases, these types of preferences are also not visible on the user edit form, so manual updating is not possible.

This change means that preferences of this type will now be always automatically be updated as required whenever a user is saved.

Recruit logins (new user portal) now included in last activity reporting
User activity in the new Recruit user portal is now logged and available to view in all the standard user activity reports.

Requisition ID no longer a required field in Recruit admin requisition views
Users may remove the Requisition ID field from requisition list views in the Recruit admin portal if desired.

Resolved an issue related to API access in new Kallidus-Suite systems
The API may have been showing as access not authorised for some users, even though enabled.

Resolved an intermittent issue with the Share vacancy page in new Kallidus-Suite systems
Users may have witnessed an error message on first loading the Share vacancy page, with it loading fine on subsequent attempts. The cause of this issue has been identified and resolved.

Reference numbers and location now shown by default on vacancies pending approval in Recruit (new User portal)
This change will help approvers to identify specific vacancies, where required, in scenarios where they may currently have multiple vacancies with the same job title in their approvals list.

Analytics

Incorrect display of some characters in Excel CSV downloads in data exported from Analytics
Some characters, such as the £ symbol, were not being displayed as expected by default in Excel when opening CSV files exported from Analytics directly. This will now no longer be the case.

Pivot and pipeline reports will now display correctly in systems with a kallidus-suite URL
An issue has been resolved which was preventing pivot and pipeline reports from displaying as expected for some customers.

Recruit configuration tools (System Builder)

New configuration to allow setting of relevant login server for single sign-on (SSO)
Customers may be added to various different Kallidus login provider servers. This release introduces a new field to allow the relevant one to be set, depending on which server a customers SSO is added to.

This setting may be found in the IDS URL field on the main configuration page.

Improvements to trouble shooting of system publish failures
When a system fails to publish, the relevant error message will now be displayed directly on the page in System Builder, as well as logged in the error log. This should make it quicker to diagnose issues and to raise support requests with the technical team when required.