This is version 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 . It is not the current version, and thus it cannot be edited.

Back to current versionRestore this version

PERSONALITY 5.05 KEY DIFFERENCES#

Overview#

Personality Version 5.05 was built on the base functionality of Personality 5.04 to add features that support new forms and technologies.

Version 5.05 continues to be available with 2 user interfaces: Browser and Administrative/Professional (java swing), however, the sizing was removed from forms. This ensures that they show better in the browser but they may not show as well in the Admin UI. 

This update brings Multi-Tenancy to Personality.

Multi-Tenancy will be based on site records. The new HRIS version made available by NEOGOV also is multi-tenancy.

Additional new functions in 5.05 merge and simplify some Payroll processes.
Other changes include additional screens, reports and functionalities, and many, many bug fixes.

5.05 marks the end of High Line putting out “Full” releases. Future releases will be based off of Personality 5.05 as small updates are needed.

Highlights of changes between versions 5.04 and 5.05.
#

Multi-Tenancy Database#

5.05 introduces Multi-Tenant architecture to the database. This architecture is like an apartment building. All clients share the front gate, the parking garage, the security, and the pool. Each client still has their own private apartment, which is where all your data is securely stored and made unavailable to anyone except you. This means no other client can access your data.

Why is this change in architecture important? This architecture allows us to provide all clients with stronger security measures, improved hardware for performance, and a code base to share product and functionality improvements easily with all clients at the same time. It also gives clients an easier transition from Personality to the HRIS platform.

If you are currently an on-premise client or pay to be a hosted Single Tenant, this change still affects you! Database updates and system configuration, including necessary changes to site codes and forms, should be in place before upgrading to Personality 5.05. You may continue to be a Single Tenant even though the new architecture makes it possible for you to become Multi-Tenant.

Site Reference Column#

All Personality tables now have a SITE_REFERENCE_ID column added to them. This is required to enable the Multi-Tenant database structure. The values required for this column are populated automatically as part of the upgrade to version 5.05. Once active in 5.05, this column is updated each time a new record is added to the database. In the new multi-tenant database, users are limited to the SITE_REFERENCE_ID associated with their user login. This is referenced as the “Tenant” code. The “Tenant” code is the “Site Reference” code seen on IMST.

New Lexicons#

There are two new fixed lexicons included in the 5.05 release.  The lexicons X_TABLES_NO_SITE and X_TABLES_PARTIAL_SITE identify the tables that are exceptions to the population of the SITE_REFERENCE_ID. 

Both lexicons list tables defined by preloaded values. These are typically provided in seed data that are not subject to change.

Tables not listed in either of these lexicons must have a reference to a tenant site and can be viewed and modified only by that tenant.

Note - These lexicons are both fixed and should not be changed by Users.

X_TABLES_NO_SITE  #

This lexicon lists tables with records that can never be updated or customized by a client.  These are generic values, which are the same for every tenant, and tenant-specific records will never exist for these tables. 

For example: States and Provinces do not change by tenant. These records will never contain a reference to the tenant-specific site code but will instead have 'No Site'.

X_TABLES_PARTIAL_SITE#

This lexicon lists the tables in which clients are allowed to add new, tenant-specific records to customize their experience.
Since some records will have the site ID populated and others may not have a site reference, these tables remain ‘Partial Site’.

For example, Functions (IMFN) - every tenant has access to the forms that are provided while still having the option to create their own functions & forms for their users.
The “Pre-Loaded” (supplied) function does not contain a reference to any specific tenant sites.
Any “User Defined” new records (User Created) will have a reference to the tenant site which created it. 

New Database Function
#

To ensure the SITE_REFERENCE_ID column is populated correctly, on all INSERT triggers, the P2K_SESSION.DETERMINE_SITE function will pull from the values documented in the lexicons above if the site is NULL. The value inserted into the SITE_REFERNCE_ID will not be changed on any subsequent updates to the record.

Before going through the upgrade, review the value of your current Site Code (IMST) as this will have an impact on some DB user names and roles (see section “New Admin Users”). We recommend keeping the site code short if you’re still using the Admin User Interface. Site records on IMST will be set up for the Base site and the Master site.

Changes to Forms#

Maintain Form Definition (IMFDH)
#

The IMFDH screen is one of the key places where users may notice changes in the multi-tenant environment.
In the new multi-tenant set-up, users are not able to make any changes to preloaded data, including form definitions, unless logged in as a MASTER (Admin UI) user.
Preloaded screens will still allow the addition of fields as long as they are “User Defined”. Any preloaded aspect of the form will no longer be modifiable. It has always been a best practice to not alter the default set up of a form. In Personality 5.05, this practice is not just best practice; it is now a requirement.

User Profile Changes (IMUS)
#

There are several changes to the ADMIN user roles in 5.05. The P2K user profile should no longer be used within the Admin or Browser User Interface. The P2K user profile has been replaced by MASTER and MASTER_[SITE_CODE] user profiles. The P2K_USER role, as defined on IMRO, is still a requirement for all users and should be included in all user profile setups, including these new administrator profiles.

P2K User Profile
#

The P2K user profile should no longer be used to log into the application in the Admin User Interface. 
The P2K user profile will not have access to any data and should be treated as a “Schema” only.   If you sign in as P2K, the system will appear to be empty.  
The P2K user profile user is replaced with the MASTER_(SITE_CODE) user profile. 
The P2K user profile can still be used to see everything at the Database level. 
Symmetry is site independent with installation and the owner is still under the P2K schema.

MASTER User Profile
#

The MASTER user profile is used to access and modify global data. In the SAAS model, this user is not accessible to end users. In the non-SAAS model, MASTER is added to every database.  
Custom integrations, links, ODBC connections, etc. that currently use P2K need to be changed to the Master user of the base site. The P2K user profile can be used to access data at the DB level and the MASTER user profile should not be used.
Preloaded items cannot be changed from any sites except the MASTER. While MASTER can modify forms, it is not the recommended practice.
When logged into the Admin User Interface, the MASTER user profile is not able to access any employee data. A new entity was created named ADMINISTRATION. This entity and all its related data are visible to the MASTER user alone. This entity is hidden from all other user types logging into the environment.
The SITE CODE for the MASTER user profile on IMST is MASTER.

When accessing the Browser UI, the MASTER user profile is associated with an identity record on IEID called “Super User.” 
The Access Code used to log into the BROWSER UI on IEID is ADMIN_MASTER.  
The User Profile associated with this identity record is MASTER

MASTER_[SITE_CODE] User Profile
#

While the MASTER user profile controls the records that are global in nature, a site-specific admin user is also required. The MASTER_[SITE_CODE] user profile now replaces the P2K user profile when accessing the User Interface. 

In this document [SITE_CODE] represents the value found in the SITE_CODE column found on IMST.
After the database is loaded and prior to installation of the 5.05 software, please update the site code (IMST) to make the code meaningful and to not have spaces or dots. Once the 5.05 software is loaded, the master admin and self-service users are created using the site code.  
P2K preferences and logics (i.e. Setting preferences on forms, Establishing Report Parameters, Publishing Usercalcs,etc) will be transferred to the MASTER_(SITE_CODE) user profile.
Preferences that are noted as Global should be established using the new MASTER_(SITE_CODE) profile.
Note - To avoid any conflicts, all scheduled jobs should be canceled before any major upgrades and then rescheduled after. 

The username to log into the Admin User Interface is the MASTER_[SITE_CODE] from IMST
For example: the site code in our test environment is TRAIN, therefore the sign-in user is MASTER_TRAIN.
After completing the upgrade process, users may initially log in with the password “p2k”. It is highly recommended that clients change their password as soon as possible.

Site data is only visible to a user logged into that site. 

When accessing the Browser User Interface, the MASTER_[SITE_CODE] user profile is associated with an identity record on IEID called “Super User1”. The number in the name of the user increases with each new tenant record (User1, User2, User3, etc.). Most clients are not expected to have more than one tenant record. 

The Access Code used to log into the BROWSER user interface on IEID is ADMIN_MASTER_[SITE_CODE].  

This identity record’s user profile is MASTER_[SITE_CODE].

Payroll Process Smoothing

UPPAY - Payroll Batch Audit and Pay Calculation Report 

UPPAY is a new function that allows payroll users to do both the audit and calculation of pays using one function. This merges UPAUDT ‘Payroll Batch Audit Report’ and UPCALC ‘Pay Calculation Report’. The new function does the UPAUDT for selected Payroll and Batches and if batches are balanced and audited, then it automatically runs UPCALC. If there is a correction that requires UPUNDO ‘Undo a Pay Run’ and brings at least one pay header to a ‘To Be Audited’ stage, UPPAY can be run again after the UPUNDO is complete. UPPAY uses single thread processing.

UPCLOSEPAY - Close and Disburse Pay 

UPCLOSEPAY is a new function that allows payroll users to close the pay runs and disburse them using one function. This merges the UPCLOZ ‘Close a Pay Run’ and UPDISB ‘Disburse Pay’ for pay runs. The function does the UPCLOZ for the selected payroll and pay runs and then UPDISB for the same payroll and pay runs. If there is a correction that requires UPUNDISB ‘Undisburse a Payrun’. run UPDISB after the UPUNDISB.

Transaction Loading 

Location and Tax Jurisdiction Information can now be loaded to IPTL ‘Manage Loaded Pay Lines’ and processed by UPTL ‘Loaded Pay Transactions Report’. UPTL now supports the creation of Pay Headers with this information overridden and creates multiple timesheets if multiple jurisdictions are found. The new fields added are HOME_JURISDICTION, WORK_JURISDICTION, and WORK_LOCATION.

General / Miscellaneous

Field Sizes Increased

Column sizes and field sizes were increased for the fields below. Server code referencing these fields was updated to support the increased sizes.

Passwords increased from 16 to 30 characters

Columns with the domain Code increased from 16 to 60 characters 

Columns with the domain Description increased from 50 to 200 characters

User Profile added to Employments

Self-service user profiles can now be attached to an employment. When an employee is terminated and then re-hired, the older employment record can have a different, more restricted user profile.

HELP_URL

Personality 5.05 supports linking the Wiki (also known as Knowledge Base or Internal Wiki) to the role level using the updated HELP_URL preference. With this change, regular self-service users can have a different Wiki than Administrators. The preference HELP_URL was updated to have the "Applies to Role" toggled on. This automatically sets the preference at the role level on IMRO. If this preference is set at the site level on IMST, this will be used for all users except those who have this overridden on their role (i.e. WWW_EMPLOYEE role).

Open Enrollment 

Flex Plan Running Amounts and Totals are now displayed in Self Service Open Enrollment.

Feature added to allow the system to determine which plans/coverages are dependent on other plan choices. A new table P2K_BE_PLAN_DEPENDENCIES (BPD) was created. 

Personnel Action 

ISPY PA Type Tables can now be updated automatically with the new columns once a PA is created (‘Create/Refresh All PA Columns for Tables’)

New function ISFPT ‘Maintain Function PA Types’ is the screen to set up a function’s PA Type.

This form contains the PA Type that is associated with a function.

Each function can only be linked to one PA Type.

A PA Type can apply to multiple functions.

Removed PA Type field from the IMFD and IMFDH screens. 

New Functions

Below is a list of new functions in 5.05.

FUNCTION - Analytics Dashboard	DESCRIPTION
DASHBOARD_CONF	User Configurable Dashboard
MSS_DASHBOARD_CONFIG	Mgr. Configurable Dashboard

FUNCTION - Analytics Dashboard Panel	DESCRIPTION
BBDD	Benefits Dynamic Dashboard
BBSH	Benefits Static Dashboard
BDATDM	Dash - Approvals to Do
BDQL	Dash - Quick Link Icons
BECTA	Dash - Emergency Contacts (Admin)
BEDD	Human Resources Dynamic Dashboard
BESH	Human Resources Static Splash
BET4	Print My T4 form
BEW2	Print My W2 form
BPDD	Payroll Dynamic Dashboard
BPSH	Payroll Static Dashboard
BPTC	Dash - Total Compensation
BTADD	Time and Attendance Dynamic Dashboard
BTASH	Time and Attendance Static Dashboard
BWTDM	Dash - Workflow to complete

FUNCTION - Interactive Screen	DESCRIPTION
IDVARA	View All Approval Records (Admin)
IMSOIC	Candidate Document Signoff by Doc
IMSOIE	Employee Document Signoff by Doc
IMTRM	Maintain Trace Modes (Changes lost after restart)
IRNB	Maintain NGV Benefits
ISFPT	Maintain Function PA Types

FUNCTION - Report	DESCRIPTION
REBES2	Employee Total Compensation Statement
RPGLP	Payroll G/L Distribution Report
RPGLX	Payroll G/L Distribution Report
RPW2W4TB	Produce W2 forms

FUNCTION - Self Service Screen	DESCRIPTION
WAOD	Onboarding Dashboard
WAPSN	Deductions
WAPTSS	Enter Employee Timesheets
WAPWC	Process Wage Changes
WASPA	Maintain Personnel Actions
WAVEEP	Employee Profile
WCRAS_INTV	My Interview Time Options
WCRAS_SPLASH_INTV	My Assessments
WEPAY	View My Pay Stubs
WEPETBWD	My Time Card - Entered Time By Week Date
WETETBWD	My Projected Timesheet - Entered Time By Week Date
WEVBEN	My Benefits
WMEPR	Process Promotions
WMPTSS	Review Time Cards

FUNCTION - Update Process	DESCRIPTION
UEINH	Import Employee Hires
UEINHF	Generate Interface Format for Importing New HIres
UEPAIF	Generate Interface Format for PA in csv
UFBUIF	Create Budget Interface File
UPCLOSEPAY	Cloz and Disburse Pay
UPCTER	Change Timesheets Edit Rights
UPPAY	Payroll Batch Audit and Pay Calculation Report
UVACAMONTHLY	ACA Monthly Data Processing

New  Windward Reports

Below is a list of the new or existing reports that were converted to Windward, most are in .xlsx format.

REPORT	DESCRIPTION
RPFRS	Florida Retirement Report
RPSNR	Sundry Register
RFBU	Budget Structures Report
RPNYRS	New York State Retirement Report
UPORPERS	Report Oregon State PERS
UPWAPERSW	Report Washington State PERS

New Preferences
Below is a list of the new preferences. For more information see the system preferences page.

PREFERENCE	DESCRIPTION
ADD_CALENDAR_APPOINTMENT	The preference ADD CALENDAR APPOINTMENT will allow a user to automatically send an email and add an appointment to outlook calendar for an event (Implemented for Leave Request and Class Registration)
ALLOW DEPENDENCIES	Feature for benefits to allow dependencies on plans
DB_OUTPUT_BASE_FLDR	This preference is for new logic that allows output directory option on reports and dynamically creates and saves directory on DB
DEFAULT ESS ROLE	This preference is used to Auto assign IMUS on IEID upon hire via IEQH if the IDJB IMUS is missing.
DEFAULT_RANGE_MIDPOINT	Defaults the Position Wage Rate from the Job’s Salary Range.
DFT_PRENOTE_REQUIRED	This preference will allow the user to turn OFF the PRENOTE_REQUIRED toggle on insert. Default value is Y. If this preference is set to N the PRENOTE_REQUIRED toggle will be turned OFF. NOTE: the PRENOTE_REQUIRED toggle is turned ON only when the PRENOTE_DAYS on Payroll Bank Accounts is not null.  Setting the preference value to Y will not turn the PRENOTE_REQUIRED toggle ON if the PRENOTE_DAYS on Payroll Bank Accounts is null
DFLT ESS ROLE	This preference is used to Auto assign IMUS on IEID upon hire via IEQH if the IDJB IMUS is missing.
DFLT_ESS_EFF_DT	This preference is used for the Start Date override for IEID access begins.
DFLT_ESS_USER	When an employee is hired via IEQH or via API/conversion process, they should automatically have access to self-service. The agency should be able to have an IMST setting that is the default user profile for the identity. There should also be an IMST for the default accessor_key. This should allow for work email as this will be Neogov's approach for unique user logins