Release 148 Notes

R148 Sprint: 1/3/2025 to 1/31/2025. To learn about product features that you may not recognize, contact ClientSpace Professional Services.

Release Schedule

Release updates are implemented by the group, as indicated in the following table.

Enhancement

Enhancement groups are Change in Functionality, ClientSpace Premium (ClientSpace with additional modules), Advanced Administration, General, and Staffing.

ClientSpace Premium

Benefits Plan Manager (BPM)

Note: We are hard at work on the Benefits Plan Manager (BPM), a new product that is coming soon! As the release date approaches, we will share more details and documentation.

Other ClientSpace Premium

Case

Enhancement

57311

Created a Separate Status Field for SIDES Claims Tracking

Previously, when managing claims, the Claim Status (ClaimStatus) field, used for general claims tracking, was the only claims tracking field available for the SIDES integration. This made it difficult to break out "SIDES only" activities for examination or reporting. Now a new lookup field named SIDES Status (luSIDESStatus) has been created to track SIDES claim statuses. It uses the Unemployment Claim Status lookup group and is located in the "Additional Information" fieldset of the UI Claim dataform as a "read only" field. As you move through the SIDES claim process and click the Action Center workflow links, the SIDES Status field value updates appropriately.

 

Note: The addition of the new SIDES Status field does not replace the Claim Status field. The SIDES Status field simply allows you to isolate SIDES integration activities. Both fields continue to update as you move through the SIDES workflow as both the Claim Status and SIDES Status field values are set by the SIDES scheduled process. The statuses mirror each other unless you manually change the Claim Status field value (as Claim Status is editable and SIDES Status is not.) Any manual status you may set once the integrative part of SIDES claims processing is complete will not be reflected in the SIDES Status field. For instance, SIDES may return a final status of "Claim Answered (SIDES)" and a claimant may choose to appeal a decision not in their favor. The process for starting an appeal is not done through the ClientSpace SIDES integration but you can continue managing the claim in ClientSpace by manually setting a Claims Status (such as "On Appeal") that your company may have created to track the start of an appeal.

 

The following additional changes were required to support this enhancement:

  • Two business rules, Set Status to Information Received and Set Status to Queued were updated. The Parameter sFieldName was changed from ClaimStatus to luSIDESStatus.

  • The Scheduled Process for SIDES was updated to set the status for both status fields (Claim Status and SIDES Status).

Important:

  • In ClientSpace Release R148, the existing Claim Status field will continue to be the field of record for the SIDES process until we complete an Extranet upgrade.

  • The Claim Status and SIDES Status fields will be updated by the scheduled process as described but other processes in ClientSpace that may be using the Claim Status field, such as email templates, workflow channels and reports will continue to only use Claim Status until the Extranet upgrade is complete. After the Extranet upgrade, these other processes may require adjustments.

See SIDES Status Definitions.

71104

Made Security Update to Pricing Batch Surcharges Search

Previously, clicking the Surcharges custom link on the Pricing Batch dataform to get to the Surcharges Search form allowed users to bypass surcharge security and delete a secured surcharge for which they did not have Delete rights. Now, the Surcharges Search form has been updated to respect security settings using the same method used for the Pricing Console Surcharges section: 

  • If a user has not been assigned Delete rights for gen_Surcharge, the Delete button does not display.

  • If a user has only been assigned Delete rights for gen_Surcharge but they do not also have rights to the security entity for the Surcharge Type, when they select the surcharge in the grid the Delete button appears dimmed and cannot be clicked. To delete a surcharge type that is flagged Secured, they must have Delete rights to the gen_Surcharge security entity and Delete rights to the security entity for each Surcharge Type they are allowed to Delete.

    These entities will have a name format of SurchargeType_<SurchargeType.SurchargeCode>

     

    Example: The secured Time and Attendance surcharge type entity might be named SurchargeType_TA.

     

    This applies to all locations where the list of surcharges is accessed, including:

    • The Pricing Console Surcharges section.

    • The Surcharges Search form (which is accessed by clicking the Surcharges link on the Pricing Batch.)

See Creating Pricing.

Advanced Administration

Case

Enhancement

60484

Added "Does Not Equal" Operator for Configuring Workspace Landing Link Display Conditions

Previously, when you configured a Workspace Landing display condition and added a condition expression with a Source of Form Data, the "Does Not Equal" Operator was not an available option. The "Does Not Equal" Operator has now been added and works with the Project Code, Template Code, and Workspace Group Field values.

 

How this can help: You can now create " Does Not Equal" condition expression(s) to filter out one or more Template Codes. Before, you had to set up display conditions using only the "Equal" operator to include nearly all templates except for a typically small number of exclusions. This was time consuming for customers with many templates.

SeeConfiguring Link Display Conditions.

62477

Added Ability to Set API-Enabled Fields by API User Pipeline

Previously, there was a setting in the Dataform Field Administration under Settings named Include in API . When enabled, it made a field required for the API. For example, for the ClientSpace API, the API-enabled fields are required for Client Service Case creation. This was limiting when there were multiple API Users if each API User had different definitions of the required set of fields.

Now, each API user can now have their own definition of the required fields without impacting an API user who is running on a different pipeline.

To support this functionality, the following changes were made:

  • The Include in API checkbox has been removed from Dataform Field Administration.

Note: The Include in API checkbox on the Dataform Properties (System Admin > AdvancedDataform Admin) was not removed. The Include in API checkbox has only been removed from the Dataform Field Properties (System Admin > AdvancedDataform Admin > Fields).

  • When you click the Include in API checkbox on the Dataform Properties, a new option displays in the Action Center named API Configuration.

  • When you click API Configuration, the API-Enabled Fields window displays where you can assign a pipeline to a field. Note in the example image below that the same field can be associated with multiple pipelines.

This is what allows you to set up distinct groupings of required fields for each API User (i.e., consumer) of the API. Since each API User (System Admin > AdvancedAPI Users) should be configured with a unique pipeline (which is our recommended best practice), when you associate a group of fields with the pipeline of API User 1, for instance, you can then associate another group of fields with the pipeline of API User 2 and have some of those fields be the same as or different from those associated with API User 1. This is illustrated in the diagram below:

Note: 

  • The Describe response and the Get, Post, and Put methods of the Dataform endpoint in the ClientSpace API respect this change.

  • With this update, all currently API-enabled fields will be enabled on every pipeline that has a pipeline linking row in the Pipeline Linking table (System Admin > Pipeline Linking). Additionally, if the pipeline linking row associated with an API User does not exist, it will be created in the Pipeline Linking table with all Behaviors set to "Disallow". This is being done to mimic the previous functionality of API-enabled fields so that all of your existing API-enabled field configurations will continue to work as they did before the update.

  • This change has no impact on workflows, email template configurations or any other processes which are independent of the API definition of the form. This change only provides the flexibility of being able to define which fields are required to create a case by API User.

  • We cache the API-enabled field values for 20 minutes as we did with the previous method of defining API-enabled fields. Therefore, you should experience no impact on performance as the caching ensures that the database is not being queried for every request occurring within a recent time frame.

See Configuring API-Enabled Fields.

66177

Made Department Role Titles "Read Only".

Previously, any role Title in System Admin > Security > Roles could be edited. This could cause issues when the role was a system-generated Admin or Member role created by adding a Department record. Potential issues included:

  • An error message displaying when attempting to change the Title of a Department role where there was an already identical match to an existing non-Department role.

  • Difficulties tracking issues that occurred prior to changing the Title of a Department role.

Now, the Title field of a role associated with a Department is "read only".

Note: 

  • You can still edit the Title field of other roles not associated with an Department.

  • The following previous functionality is still supported: If you update an existing Department name, the associated roles auto-update in System Admin > Security > Roles.

See the Departmental security section of Configuring Organization and Workspace Security.

67447

Added "Force Late Loading" Option to Query (XSLT) Widget Settings to Improve Form Load Performance

Previously, when a dataform had Query (XSLT) widgets on them, the dataform would not finish loading until all XSLT widgets finished loading. . In some instances, this resulted in delayed form loading. Now, a Force Late Loading setting has been added to the Query Widget settings (System Admin Widget Layouts). When this setting is applied, a dataform with XSLT widgets will finish loading even if the XSLT widgets on the page have not finished loading. Placeholders for the XSLT widgets will be visible on the dataform while they continue to load.

 

See Widget: Query (XSLT).

69346

Updated HE_RequireRateGroup Business Rule Method

The Excecution Pipeline and Primary Trigger Value for the HE_RequireRateGroup business rule method have been updated as follows:

  • "Imports" was added to Execution Pipeline.

  • Primary Trigger Value was set to "Selected".

69664

Added Employee Termination Letter Word Merge

A new Employee Termination Letter Word merge stored procedure named peo_merge_ee_termination has been added to System Admin > OutputsMerges. It is designed for PEOs to send letters to their client's employees informing them that the PEO is canceling their agreement with them.

 

Note: Currently, to use the Employee Termination Letter merge, you will need to add the merge record and a custom link. (See Merges and Configuring Custom Dataform Links . If you need assistance, please log an Extranet case.) In an upcoming release, we will add a pre-configured merge record and custom link as well as a filter page.

 

See Employee Termination Merge.

70522

Enhanced "More" Search in Manage Import

Previously, you could not perform a More search by Date Created or Created By on the Manage Import dashboard (System Admin > ImportsManage Import). Now, Date Created and Created By filters have been added to the More search of Manage Import.

70403

Added Business Rule Title Display to the ClientSpace Work Center

Previously, when you had multiple, open business rules open, the Work Center (i.e., left navigation pane) did not list the name of the business rule which made it difficult to identify rules and switch between them. Now, the value in the Rule Title field of the Business Rule (System Admin > AdvancedManage Rules) displays in the Work Center for ease of rule identification when multiple rules are open.

 

70536

Added API Custom Stored Procedure Security

API custom stored procedure security has been added to prevent an API User from accessing custom search queries developed for other API Users using an API software such as Swagger or Postman to access the stored procedure.

 

Now, custom stored procedure security is managed with security entities and roles. The roles are auto-generated for an API User when you enable a stored procedure on the new Proc Access tab on the API User dataform (System Admin > AdvancedAPI Users). Developer users can check or uncheck the Access checkbox to grant or deny access to custom search queries. This controls which stored procedures an API User can call in the API software parameters as well as what they can see in the Describe response. In the Describe response, users only see the stored procedures assigned to them. If they try to adjust the parameters to run a stored procedure without access permissions, the following message displays in the Response Body: "You are not authorized to perform this action."

 

Note:

  • Only Developer users can manage API custom stored procedure security.

  • Only API custom stored procedure entities display on the new Proc Access tab. Other security entities will not display here.

  • When an API User is assigned access to a custom search query procedure, a new role is also created for them in System Admin > Users. It displays under Roles in the Action Center and you can delete a role from here. It is the same disabling the role on the Proc Access tab of the API User dataform.

  • With this update, all custom search query procedures are configured with access to the API custom stored procedures to prevent loss of access to existing API custom search queries. Developer users can restrict unauthorized access to existing procedures and grant or restrict access to new procedures going forward.

See Configuring API Custom Stored Procedure Security.

70879

Added Ability to Store Survey Results as Integer Metadata for Use in Reports

Previously, survey rating results were stored as characters instead of numbers. As a result, you could not perform calculations such as a mean average of results on reports. Now, you can store survey rating results as numeric value (i.e., integer) metadata and use the metadata in Business Intelligence reports.

Example: If four survey recipients select 10 on a 1-10 point star rating scale, an integer value of 10 is associated with their selections. If another survey recipient selects 3, an integer value of 3 is associated with their selection. You can then use the integer metadata in BI to calculate an average score of 8.6.

To support this change, the following changes have been made:

  • A new Survey Metadata dataform has been added. It contains a single field labeled Survey Rating (Integer Only). The field is used to store a survey response using the integer equivalent of each survey rating value.

    Note: This is a multi-form.

  • A new field, also labeled Survey Rating (Integer Only), has been added to the Lookup Details dataform of the Survey.

    With this update, default integer values have been assigned to the pre-configured survey rating lookups listed below:

    1 - 10

    10-point rating scale used for the default survey layout. Valid default options range from 1 to 10 (with 1 = Very Poor and 10 = Excellent). Default integer equivalents are also 1 to 10.

    Frequency

    5-point rating scale. Valid default options are Always (10), Often (7), Usually (5), Sometimes (2) and Never (0). Default integer equivalents are shown in parentheses.

    Agree

    5-point rating scale. Valid default options are Highly Agree (10), Agree (8), Neutral (5), Disagree (2), and Highly Disagree (0). Default integer equivalents are shown in parentheses.

    YesNo

    Valid default options are Yes (10) or No (0). Default integer equivalents are shown in parentheses.

    You can edit default assignments if necessary. For custom survey rating lookup values that you added on your own, you must enter the integer values on the Lookup Details dataform.

  • A new business rule named Set Survey Results Integer Value has been added. This rule uses an existing business rule method, _SetFieldFromLookupMetadata. The rule is triggered when survey results are saved. It sets the saved integer survey rating value in the Survey Rating (Integer Only) Survey Metadata dataform.

  • Once the numeric survey results are saved on the Survey Metadata dataform, you can select gen_csSurveyResults, the SurveyRating lookup value and METADATA - Survey Business Intelligence report Data Sources and use the data to create BI reports containing survey result calculations.

  • The Uses Metadata column is now set to Yes by default for all Survey Rating Lookup Group values on the Lookups dashboard.

See the Working With Survey Results section of Configuring a Dataform Survey Email Template.

70668

Standardized the Fields Displaying in the Administrative Fieldset

Previously, Administrative fieldset fields on ClientSpace CORE forms did not consistently display all of the following fields:

  • ID 

  • GUID

  • Date Created

  • Date Updated

  • Created By

  • Updated By

These fields are now always displayed on CORE forms to Global Admins.

General Enhancements

Case

Enhancement

55737

Added a Description Field to Dataform Field Properties

A Description field with a 1000-character allowance has been added to dataform field properties (System Admin > Advanced > Dataform Admin> Action Center > Fields).

Use the Description field to specify how and where a field is used in ClientSpace. This can help with dataform field maintenance activities, such as:

  • Determining which unused fields to delete.

  • Reorganizing fields on a form (i.e., determining fieldsets to group fields.)

Note: Once you add Description text, you can view it from the Dataform fields list without needing to open the field properties record when you hover the mouse over the field name:

Very long descriptions may be truncated. In those cases, you will need to open the field properties record to view complete details.

See Adding Dataform Fields.

68530

Modified Client Service Case Type Configuration and SetDueDateFromCaseTypeOffset Business Rule Method to Use Business Days When Calculating Due Date

Previously, the SetDueDateFromCaseTypeOffset business rule method always used calendar days to calculate the Due Date OffsetClosed The Due Date Offset is an optional setting on the Client Service Case Type configuration used to set the Due Date on the case automatically. For instance, if you want the Due Date on the case to be automatically set as 5 days from the date the case was created or updated, enter a Due Date Offset of 5.   ClientSpace business logic then applies the Due Date Offset based on Case Type and sets the date automatically on Save if the Due Date field on the case record is currently empty. If the Due Date has been set manually, it will not be overwritten. used to set the Due Date on the Client Service Case dataform.

 

This caused the case response to become overdue too quickly in some instances. For example, a case created on a Friday with a Due Date of 3 days or less could be overdue by Monday because weekend non-business days were included in the Due Date Offset calculation.

 

Note: The previous example is of an environment with a typical five business day (Monday through Friday) work week. ClientSpace can accommodate atypical business day/work week configurations. The ClientSpace install settings contain fields used to determine business hours and business days: Business Open, Business Close, Business Week Begin Day and Business Week End Day. If you require help with these settings, please log a case with your Professional Services representative.

 

Now, a new Due Date Offset Method field has been added to Client Service Case Type configuration in the Admin Workspace and the SetDueDateFromCaseTypeOffset business rule has been modified to use the Due Date Offset Method.

 

When the Due Date Offset Method is set to Business Days and the SetDueDateFromCaseTypeOffset business rule method is triggered (by saving a new case or by saving an update to an existing case), the SetDueDateFromCaseTypeOffset business rule method calculates the Due Date Offset based on Business Days.

 

The SetDueDateFromCaseTypeOffset business rule method was further modified to exclude holidays entered in the Company Holiday table from the Due Date Offset calculations when the Due Date Offset Method is set to Business Days.

 

Note: To preserve your existing configurations, Due Date Offset Method defaults to Calendar Days. Update case type records to use Business Days where required.

 

See Configuring Case Types and Business Rule Methods.

69993

Enhanced "More" Search on Multiform Dataforms

Previously, some multiform Closed A ClientSpace dataform where there may be multiple forms per Client Workspace, such as Locations. The Multi dataform has a one-to-many relationship with the Workspace, such as physical locations for a client, or paycheck records for an employee. An example of this is the Employee dataform. dataforms in ClientSpace did not allow you to perform a More search by Date Updated or Date Created. Now, multiform dataform searches include a Date Updated and Date Created filter.

 

Note: This change also affects the ClientSpace API. It will now allow a Date Updated and Date Created filter.

69343

Added Injured Employee Wages Report to Comp Claim

A new Injured Employee Wages Business Intelligence report has been added. It shows an injured employee's wages based on the Comp Claim. You can run the report from a Comp Claim by clicking the Wage Report link in the Action Center under Reports.

See Generating an Injured Employee Wages Report.

70892

Added Home Link to the Company Logo

Clicking the Company Logo now opens the default Home page. It works the same clicking the Home icon in the Work Center area:

See the Selecting a Home Page section of Home Page and Home Page Widgets.

Fixes

Case

Issue summary

Resolution

68207

Corrected Description on CreateClientServiceCaseAndTasks Business Rule Method.

Previously, the description of the CreateClientServiceCaseAndTasks business rule method in System Admin > Advanced > Manage Rules was incorrect.

 

The Description field now displays: "Ensures the Case Number is set correctly on initial creation, clones Tasks and Distress Calls by Case Type on initial creation, and renames related tasks appropriately if an Employee is specified on the Case."