[MU-HR-5-A]
Actions and Employee Self Service
Munis: Human Resources
CLASS DESCRIPTION
This session will explore the Personnel Actions entry module, how to create personnel actions, managing
personnel actions, and different setup options. The different posting options and numerous reporting
tools will also be discussed. The session will explore how to set up Employee Self Service to allow
employees to initiate their own personnel actions to accomplish common tasks: (i.e. name change,
address change, dependent changes, etc.). The session will also explore the 3 main use cases for
personnel actions: (New Hires, Terminations/Reinstatements, and Personnel File Changes)
OVERVIEW
The Personnel Actions Entry module is designed to aid in the data entry process by making changes in a
timelier manner, allowing for a greater level of security, providing customizable workflow processes
unique to the changes being entered, as well as provide a means of historical tracking and report
functionality. All of these features combined should make Personnel Actions Entry the preferred method
for most, if not all, employee related changes made within the Payroll / Human Resources module.
Security
Personnel Actions Entry provides added layers of security. Changes made in Employee Master, Employee
Job/Salary, etc. affect LIVE payroll data directly and will immediately effect the payroll. Changes made
directly in these programs are not subject to oversight or review nor are these changes subject to
approval by authorized users prior to impacting the payroll. By utilizing Personnel Actions Entry as the
method for making employee related changes a much higher level of control and oversight is gained,
which will ultimately lead to fewer data entry errors and more accurate payroll processing.
Timing
If changes are made directly into the Employee data records (Employee Master, Job/Salary, etc.) those
changes impact the payroll process immediately. Often, however, changes to employee data can be
known in advance and do not take effect for weeks (employee promotions, pay increases, changes to
benefits, etc.). The Payroll Generation process looks at the information that exists in the employee profile
at the moment the process is run. If a change to an employee pay rate or deduction amount shouldn’t
take effect until some future payroll period these changes would need to wait until the Payroll
department has completed processing on the last payroll that should use the OLD information. With
Personnel Actions Entry, actions are entered with an effective date, thus allowing the opportunity get the
information entered into the system the day the request is received or determined and have the changes
posted to live once the effective date arrives. From a workload standpoint this allows for data entry tasks
to be dispersed more evenly rather than attempting to enter data within the payroll period in which it
becomes effective.
Efficiency (Decentralized Entry)
With the addition of Employee Self Service initiated actions, the Personnel Actions Entry process offers
several means by which data can be entered. Employees can initiate Personnel File changes directly from
Employee Self Service which provides a much higher degree of accuracy since the changes being
requested are being entered directly by the employee. Changes can also be entered into the Munis
system by decentralized HR departments and routed and reviewed (using workflow) to ensure the
changes are accurate and are appropriately entered based on the desired business practices.
Workflow
With multiple workflow rules that can be defined, different types of personnel actions can be routed
based on the type of changes contained within the personnel action change package. Some personnel
actions may require multiple reviewers and complicated workflow paths, while other simple changes
(Address / Phone Number / Emergency Contact changes) may require far less oversight. Workflow can be
used as a tool to notify users when pending changes have been entered and released for approval.
Reporting
Built in reports will provide quick access to pending changes being made within each personnel action.
These reports can be run any number of times before the changes are finally posted updating LIVE payroll
information. In addition to run-time reporting of changes currently pending, after a change is posted to
the LIVE payroll information, the changes can be archived to the actions history program which can log a
record for every personnel action that is created, approved, and posted. These historical records can be
used as a reporting tool to help answer many various high level questions about historical changes made
to a single employee, or on a broader scale to answer questions about hiring practices, termination
practices, benefit changes, budgeting changes, etc.
High Level overview of PA
To fully understand the process of how the data is manipulated and maintained and how the pending
changes can avoid impacting current payroll processing it is important to understand the process by
which a Personnel Action is created.
When a new Personnel Action is created, Munis makes a copy of all the data that can potentially be
manipulated as part of the personnel actions data entry process and stores it separate from the data that
is examined when running payroll processing. NOTE: Not all employee data is copied to the pending
personnel actions, only data that is heavily maintained and would potentially impact payroll processing is
copied to the separate set of data. This separate copy of data is typically referred to as the actions
sandbox or the actions data set. This copy is what is being maintained during the data entry process
within personnel actions entry. The live data set from which the data is copied will remain unchanged
until the actions data set is posted and updates the live data that ultimately affects the payroll.
2
Below is a diagram that will hopefully make the process easier to understand from a visual perspective:
1.) Personnel Action is Started: This process can be initialized from several places within Munis.
(Personnel Actions Entry, Salary Change programs, Employee Self Service, etc.). Creating a
personnel action creates a copy of all employee related data that will potentially be modified
during the employee data entry process.
2.) Personnel Actions Data (Copy of Live): At the very beginning of the personnel action processing,
the data that exists in the actions data set (sandbox) and the data that exists in the live data set
(data affecting payroll) will be identical. Changes made in the live data after the creation of the
personnel action will not be reflected in the personnel actions data. Changes made to the
personnel actions data set will not be reflected in the live data set, until posted this is intentional
to provide a data entry process that is independent of the live payroll data.
NOTE: Since changes made to live are potentially occurring at the same time that data is being
entered into the personnel action, it is vital to ensure that changes that are being made in live do
not adversely affect changes being made in the personnel action. Personnel Actions has processes
to avoid data conflicts and resolve them in the most appropriate ways possible, however when a
conflict arises and a choice is necessary to be made, the personnel actions data will always
overwrite live data with data found in personnel actions data set. (See the ‘Posting’ section for
more details about conflict avoidance and resolution).
3.) Employee Data Entry: This is where the data changes to the employee profile can be made. Most
of the data entry will occur using screens identical to the screens designed to maintain the live
data set. (Please use caution to make sure changes are being made to the correct data set.)
4.) Employee Changes are Reviewed / Approved: This step in the process is where workflow rules
are applied and notifications and approvals are entered to ensure data entry and business
practices are adhered to properly.
5.) Output-Post: This is the final stage in the process where data changes are aggregated and conflict
avoidance and conflict resolution occurs. Assuming changes are approved and posted to the live
data set, actions history records can be created and changes will update live in a timely manner
based on the effective date of the personnel action.
3
SETUP
The Personnel Actions Entry module has several different setup processes that should all be carefully
analyzed before implementing a naming / setup scheme. As with any implementation process making
poor decisions during the initial design / setup process can cause future processing to become much
more difficult and require significant effort to work around rising challenges and changes to the
Personnel Actions module over time.
Security and Permissions
Security can be setup at the role level to control access to personnel actions. All of the same permissions
that can be applied in the live data set, can be applied to the personnel actions data set. This allows
existing permissions to be copied and applied directly to the personnel actions data set. This separation
of permissions allows a user to be granted view only access (inquiry only) to the live data set, and
update/delete access to the personnel actions data set. This would require that all changes that need to
be entered would have to be entered through a personnel action where security and workflow rules are
the strongest.
LIVE DATASET
ACTIONS DATASET
The Role Maintenance program provides 5 distinct permissions that can restrict access to varying degrees
of security.
4

No Access: User will not be allowed to view any data in the program. In most cases the program
directly associated with the category will cease to open.

Update/Delete: User will have full access to add/update/delete records in the program directly
associated with the category.

Hide SSN (Upd/Del): This permission behaves identically to the Update/Delete option, with the
limitation that the SSN would be restricted from view. (See SSN Security Note below)

Inquiry Only: This permission will allow the data to be viewed but not modified. This should be
used for the Employee Master data set (Live) when all changes should be made through
personnel actions entry.

Hide SSN (Inquiry): This permission is the same as the inquiry only permission, but with the
addition restriction that the SSN should also not be seen.
NOTE: SSN Permissions should only be given to users who require access to maintain the SSN. Only users
responsible for adding new employees are required to have access to the SSN in order to complete the
new hire process. All other users are not required (from an application standpoint) to see or edit the SSN.
In addition to role category permissions, data access permissions will also be adhered to when in the
Personnel Actions Entry module. These restrictions can be defined to further decentralized access to
specific employee data based on: Location, Deduction, Org code, and Pay Types. Applicant data
restrictions are not applied within the Personnel Actions Entry module.
Personnel Settings
The Personnel Settings program has several parameters that can be set to control functionality within the
Personnel Actions Entry module. While some of these settings uses may seem unclear at this point in the
document, their purposes will hopefully make more sense as you review the remaining parts of this
document.
5
Print Single PAF: This option is used when posting more than one action at a time. If multiple
Employee Personnel Actions are being posted for multiple employees this will combine all the PAF
(Personnel Action Forms) data into one single PAF file, rather than having one file per employee.
Use Primary Job for Action History: When posting personnel actions and creating actions history,
the job class and pay information that is stored on the actions history record can either be based
on the job class of the pay records that are actually modified or always pulled from the
employee’s primary job class employee job / salary base pay. If more than one base pay is
modified the primary job class will always be used, otherwise non-primary job classes can be
reported if no other base pays are modified. This option once set, should not be modified to
ensure consistent reporting methodology.
Allow Actions Post to Projections: (New in 11.1): Traditional posting from a personnel action will
post to the live data set. This is the primary purpose of a personnel action, to queue changes to
later be posted to live. However, with recent modification requests we’ve extended this capability
to allow personnel actions to be posted to other data sets that exist within the Munis Payroll/HR
system. This option enables the ability to post to salary and benefit projections that are currently
assigned to the user running the personnel actions output post. The implications of this process
are complex and would require a significantly long explanation far beyond what will be discussed
in this document. Additional information can be found in the Munis Knowledgebase regarding this
new process.
Action Code Setup
There are three distinct code files that are used in the identification of a personnel action and ultimately
determine what workflow process the action uses, additional optional behaviors specific to the code
6
being used, how personnel actions are categorized for reporting, etc. As mentioned above, the setup of
these codes should be carefully planned before implementing a code scheme.
ACTION CODES
The action codes program is the primary code based program that is used in the personnel actions entry
module. This program controls the behavior of the primary action processing codes. The codes should
remain as generic as possible. These codes are the only required code setup, though the additional codes
discussed later will help to further elaborate on the meaning of codes setup in this program.
Action Code: As mentioned above the code naming scheme should be carefully considered. This 4
character code will control the behavior of the action.
Category: This category controls the behavior of the action, as well as the workflow process that
is utilized. N – New Hire actions will force the input of an employee that does not currently exist in
the live data set. R – Reinstatement will force the input of an employee that exists in the
terminated data set being moved back to live. See below for more details regarding each category
and any special behavior it provides.
Short Description: This is a 10 character field that briefly describes the code.
Long Description: This is a 30 character field that describes the code in more detail. NOTE: This
description will appear on ESS for actions that can be submitted from ESS. Caution should be used
when describing the action code since it will be visible by employees on ESS.
Default Program: When a personnel action is created using personnel actions entry, a default
program can be launched saving the user the trouble of having to navigate to that program to
7
perform data entry. This is especially useful when the only changes that are necessary for a given
action code are found exclusively in one program. For example, address change, or direct deposit
changes.
Default On/Off Board: This code specifies the on-boarding/off-boarding code that will be
associated and pre-populated when using the entered action code.
Survey Code: This is the survey that will be generated as a result of posting the action. User will
still have the option of whether the survey should be generated or sent.
ESS Template: This option controls which ESS Template will be used when submitting action entry
requests from Employee Self Service. (This will be discussed in detail further in this document).
Attachment Type (11.2): As of 11.2, when attachments are added via Employee Self Service, the
attachments will now be coded with a specific Attachment Type. These Types can be translated
into TCM attachment types if TCM is being utilized.
Civil Service Action: This checkbox will mark an actions as a Civil Service Action, which will provide
a restricted data entry mode specific to Civil Service Employee tracking functionality.
Print Personnel Form: This checkbox will control whether the action, when posted, will generate /
be included in the Personnel Action Form (PAF).
Action History Default: This checkbox will control whether the ‘Creates Actions History’ checkbox
will be checked on the Personnel Action. This can be overwritten during entry, this option simply
defaults the checkbox on the Personnel Action when this code is used.
Allow Job Change: This checkbox enables the Job Change menu option. This option does not
prevent modifications to Employee Job/Salary or Employee Master in regards to the Employee’s
Job Class.
Show Interviews: This checkbox controls whether the Interviews tab on Personnel Actions Entry is
hidden or enabled.
Show Replacement: This checkbox controls whether the Replacement tab on Personnel Actions
Entry is hidden of enabled.
Reset Workflow: This checkbox controls whether changes made within the personnel action, after
the action is released to workflow, causes the workflow to be restarted. (NOTE: The workflow
restart is initiated whenever the record is displayed or proof-posted.)
Action Categories:
Other than the code value and the description values, the category code is the only other required field.
This field controls the main behavior of a code and each category has its own workflow business rule. The
chart below will outline each of the categories as well as discuss the functional differences for each
category.
Category
Description
Business
Rule
Unique Functionality
Typical Use Case
A
Attendance
PMD
None
Used for years of
service adjustments or
accrual modifications.
8
B
Benefit Change
PMB
None
E
Evaluation
PMW
- Generates Evaluation
specific PAF
I
Injury/Incident
PMI
None
L
Leave
PML
N
New Hire
PMN
O
Other
PMO
R
Reinstatement
PME
9
- Evaluation Score, Leave
Length, Return Date, and
Impact Seniority fields are
enabled on action header.
- Return Date is a required
field.
- Generates New hire
specific PAF.
- Launches Condensed
Employee Master as its
default program.
- Potentially generates a
probationary evaluation.
- Requires SSN and DOB
permissions to complete.
- New Hire must specify a
new employee number.
(Employees who exist in
the Terminated data set
will require ‘R’ category).
None
- (For Employees already
Terminated) Data is initially
copied from the
terminated data set.
Used for changes to
benefits.
Used for changes to
evaluations.
Used for changes
made as a result of an
injury, accident, or
illness.
Used to record when
an employee will be
out of work for
extended leave.
(FMLA, Military,
Injury, etc.)
Used when hiring /
adding new
employees.
Typically used when
making demographic
changes. (Name,
address, phones, etc.)
Namely when changes
need to be made that
don’t fall under any
other category.
Used to re-hire or
reinstate an employee
- (For Employees already
Terminated) Data is
updated in the terminated
data set before being move
back to the live data set
during posting.
- Launches Condensed
Employee Master as its
default program.
- Potentially generates a
probationary evaluation.
- Can also be used for
employees who have been
Inactivated in Live.
from the Terminated
Employee file.
Used when
modifications are
made to Employee
Job/Salary. (Job
Change, Transfer,
COLA, stipends, etc.)
S
Salary Change
PMS
None
T
Terminate
PMT
- Causes accrual data to be
printed on the PAF.
V
Civil Service
Validation
PMV
None
Used for employee
termination or
separation.
Used for all actions
relating to Civil Service
Employee tracking.
Action codes that use
this category should
also be marked as a
civil service action.
REASON / AUTHORIZATION CODES
The Reason/Authorization codes are optional so far as Munis is concerned. They can certainly help to
expand your Personnel Action Code schema to provide sufficient detail so that the action code itself
describes fully the “What” and “Why” for each of the actions you perform. The biggest advantage to
using Reason/Authorization codes in your coding schema is to allow you to define a more detailed
workflow notification and approval chain. The Reason/Authorization can be specified as part of the
workflow business rule which allows the personnel action to be routed to the appropriate user that
needs to review and approve the data that is being changed in the personnel action.
10
These codes are 4 character alpha/numeric and should further explain the action code. Any Action Code
and Action Reason/Authorization combination can be specified in personnel actions, based on this
combination the action can be further defined to better explain what is being modified and why it’s being
modified.
As shown above, the reason code can be specified as part of the workflow setup to help better route who
should be notified and who is responsible for approving the changes being completed in the Personnel
Actions module.
11
SUPPORTING ACTION CODES
The Supporting Action field is optional. If it is used, it is used primarily to add an additional layer of
description to a particular personal action. Unlike Personnel Action Codes or Reason/Authorization codes
described above, there is no impact on Munis functionality or Workflow by using or not using these
codes. Not all actions have to specify a support action code, some may specify a supporting action code,
some may not.
To set up these codes use the folder icon found to the right of the field or access Miscellaneous codes
and select the code category ACT2 – Personnel Supporting Action Code option from the list provided.
Workflow Setup
Once the action codes and supporting action code scheme has been defined, workflow business rules can
be defined to further refine the approval process of personnel actions.
12
-
If no workflow business rules are defined for a particular process, releasing the personnel action for
approval will automatically set the personnel action to the approved state. This type of setup should
only be used for processes that require little to no oversight. (Emergency Contact, or Phone number
changes are common examples.)
-
If a workflow business rule exists for the specified category linked to the personnel action code being
used, the workflow process will be initialized once the action has been released for approval.

13
There are numerous factors that are taken into consideration and can be used to route personnel
actions more efficiently to the appropriate users.

Action Code / Action Category: The action code is linked to an action category. As specified
in the table above, each action category has it’s own workflow business rule.

Group/BU: The Employee Master Group/BU code can be used to route workflow approvals.

Authorization / Reason: The authorization / reason code can be specified on an action and
specified on a workflow business rule to increase the routing capabilities of the approval
process.

Location (Ranges): The Employee Master location can be used to route approval. Ranges of
Locations can also be specified.

Job Class (Ranges): The Employee Master job class can be used to route approval. Ranges of
job classes can also be specified.

G/L Org Code (Ranges): The Employee Master G/L Org Code can be used to route approval.
Ranges of G/L Org Codes can also be specified.

G/L Segment (Ranges): The Employee Master G/L Segement data can be used to route
approval. Ranges of G/L Segment data can also be specified.
The details on how to setup workflow business rules to meet specific needs for routing will not be
discussed in detail here. There are numerous documents available on the Munis Knowledgebase to help
guide the setup of these rules.
PERSONNEL ACTIONS ENTRY
After setting up the necessary codes and workflow options and examining and choosing which personnel
settings to utilize, the Personnel Actions Entry module can be utilized to perform its basic functionality,
providing an interface to make employee data changes without effecting live and while preserving history
and providing adequate approval chains and oversight.
All of the fields on the Personnel Action Entry record serve a purpose, some are more important than
others. In this document the focus will be on the fields that have the most functionality and/or impact on
14
the processing of the personnel action. For a detailed explanation or use case of every field, please
review documents found in the Munis Knowledgebase.
Employee Number: This is the employee number of the existing employee, new employee, or old
employee for which the action exists. New employee numbers can be assigned from the Control
File, existing employee numbers can be specified, or terminated employee numbers can be
specified.
Effective Date: This is the date that the personnel action will be effective and potentially the date
the action will be posted. While this date can be updated, it is strongly encouraged to remain
unchanged. Changing the effective date of the action can have additional impact other than when
the action is scheduled to be posted.
Action Code: This is the code that drives the behavior of the action. It not only determines the
action category, but the behavior of the action itself. (See above for further details about how this
code drives the behavior of the personnel action.)
Reason/Authorization: This code can also drive the behavior of the personnel action in regards to
workflow. This code can also be used when leveraging the Personnel Actions Rapid Entry
functionality that is not discussed explicitly in this document. (Again, documentation about this
functionality can be found in the Munis Knowledgebase.)
Supporting Action: This field has no functional use other than to further specify the nature of the
changes being made as part of the action.
Creates Actions History: This checkbox controls whether the action will generate a personnel
actions history record when the action is posted.
Employee Initiated: This checkbox controls whether the action was initiated by an employee from
Employee Self Service.
Action Category: This is a display only field that is specified in the Action Code setup program.
Status: This field shows the workflow status of the personnel action. The field contains the valid
workflow status options that exist for all other workflow enabled functionality. (Not Released, In
Progress, Approved, On Hold, Rejected.)
15
Some action types may require entry on the Other tab though not generally required. As a rule, Munis
will automatically populate the fields found in the Employee Info block using information currently
defined for the employee this data is display only. Evaluation Score and Pay Off amount and Payoff Type
may be filled but these fields are used for information purposes only and are completely optional. For
Category L – Leave actions, however, you will be required to provide information on Leave Length and
Estimated Return.
NOTE: If using the Seniority Calculator feature in Munis the Seniority Impact flag is vital to this
functionality working properly. When running the calculator employee seniority can be impacted and the
number of days between Effective Date and Estimated Return will be subtracted from an employee’s
seniority total when any leave actions exist for that employee within the dates you specify when running
the Seniority Calculator program. Even if the feature is not being used, the field will still require input of
an Estimated Return date but it will be used for informational purposes only. In most HR departments
this is usually pretty important piece of information so being prompted to fill it is generally regarded as a
good idea.
16
Menu Options
17

Detail: This option will provide access to the Employee Detail menu from which programs that
store information within the Personnel Actions module can be accessed.

Output – Post: This option starts the posting process for the selected personnel actions. This will
be discussed in further detail later in this document.

Projections – Post: This option similar to output – post, starts the posting process except posting
to a salary and benefit projection data set for the selected personnel actions. This will not be
discussed in further detail later in this document, for more information please refer to the Munis
Knowledgebase.

Dates: This option launches the employee dates maintenance program. This program is useful for
viewing important dates as well as a quick interface for maintaining important dates in the
employees profile without the need to navigate to the program that contains these dates.
18

Scheduled Post: This option provides an interface for scheduling the posting of personnel actions
that have been workflow approved. This will be discussed in further detail later in this document.

Create PAF: This option allows the PAF (Personnel Actions File) to be generated without the need
to post the changes. This is a useful tool that can be used to generate custom reports.

Release: This is the standard workflow ‘release’ option and will initiate the workflow process for
the current personnel actions entry record that is displayed.

Rapid Entry: This option displays the personnel actions rapid entry screen where data edits can
occur more seamlessly and occur in one central screen without the need to go to several Munis
screens to maintain the data. This functionality however provides a far less robust data entry
process and does not provide all the menu options that can be found in the various data entry
programs within personnel actions entry module.

Job Change: This function allows for a quick interface for moving an employee from one job to
another job (or one position to another position). The interface requires very little information
and can perform the necessary modifications to the Employee Job/Salary records as well as
Employee Master.

Pos/Bud Request: This option will launch the Position Budget request application and will
attempt to find an associated position budget request based on the current personnel actions
record being displayed.
EMPLOYEE SELF SERVICE ACTIONS ENTRY
As of 11.1 Employee Self Service Actions Entry functionality was added to allow Employees to submit
requests to change their own personnel file. Certain modules on Employee Self Service already supported
the logic to generate a personnel action, this new functionality enhances that capability and provides a
more direct process for creating personnel actions. The functionality requires that ESS templates be
designed and assigned to personnel action codes. Action codes that have an ESS template defined will be
visible from the ESS Actions Entry screen.
Personnel Actions ESS Templates
Templates can be added and maintained from the new ESS Action Entry Template program. This program
allows for basic header text (which supports HTML encoding) and a set of data fields that will be exposed
and allow the employee to make any necessary changes.
Template Code: The code to identify the template. This code will be used in the action code
program to link an action code to a template.
19
Description: This 30 character description will describe the template. This description does not
appear on ESS it will only appear in the actions code program.
Documentation: This field specifies and controls the behavior of attachments in Employee Self
Service. Three options exist: None, Optional, Required.
ESS Header Text: This text field is displayed at the top of the ESS template once the type of
change is selected. Its purpose is to provide the employee with information about what can be
changed, as well as any instructions on how to populate the data.
Template Fields: This section defines the fields that are accessible as part of the template.

Field Code: The Munis field that will be exposed. This will also be the name of the field
on ESS if the ‘ESS Display’ column is not defined.

Required: This determines whether the field requires an entered value.

ESS Display: This will be the field label used on ESS (if specified).

ESS Default: If the field should have a specific defaulted value this value will be
entered into the field if the employee leaves the field blank.
ESS Interface
The ESS interface for entering Personnel Actions must be enabled in the ESS Administration settings. By
default this functionality is not enabled.
Once enabled, the ESS Interface for entering personnel actions can be accessed by employees after
logging into Employee Self Service and going to the Personal Information > Add/View Changes section of
ESS.
20
Clicking on the ‘Add a change’ option in the upper right hand corner will begin the process.
Based on the action codes that have been associated with ESS Action Entry Templates, the list of action
types on ESS may be short or long. In the case shown above, only five options are available. Once the
requested action type is selected the fields for the selected template will be rendered on the screen.
21
The fields that are required are marked with an (*). If fields that are required are left blank and the form
is attempted to be submitted a warning will be generated and prevent the submission of the change.
In this particular instance an attachment was also required and caused a warning to be generated in
addition to the First Name field being a required data entry field. Once the warnings have been corrected
the form can be submitted and a personnel action is created.
22
The created personnel action is created, released for approval, and marked as employee initiated. The
action code matches the selected action type in ESS. The effective date is entered as the date the request
was made. This can be posted after the effective date if it is not approved in the same day, but a record
of the day it was submitted is preserved. Once this action is approved by the necessary Munis user, it can
be posted just like any other personnel actions record. An output post will show the changes that were
requested from ESS.
Once the action is posted the action will be visible by the employee in ESS as a historical profile change.
23
POSTING
Regardless of how the actions is created or maintained the data will be required to be posted or deleted.
Deleting the action simply removes the duplicate employee data and cleans up the actions entry record
removes any record of the changes requested or entered. If the action is to be posted, the posting
process can be run manually or can be run automatically from the Munis Scheduler. Both processes will
review the actions for errors and build a change package to be applied to the live data set. The posting
process does its best to avoid conflicts and resolve data conflicts in the most logical manner possible.
While there are clear rules about how certain scenarios will be processed, it is important to understand
how certain scenarios process its change package to better avoid potential data loss.
Output Post
As discussed through this process, no changes made through the use of Personnel Actions entry will
impact LIVE data until the Output/Post process is completed on the pending action record. This process
can be run manually on a single record or on a “Find Set” of multiple records. If any record within the find
set has not yet been approved (Status not equal to Y-Approved) then none of the pending change records
in the find set will post. The proof report showing data elements that will be changed if/when the
approval to post is still generated but an error message indicating that “one or more actions have not
been approved” will be displayed and none of the pending personnel actions will post.
24
Even if workflow approval errors are generated, the proof will still be generated and output. This will
allow users to view the report to get a cleared picture about what fields have been modified, which
records have been added, and which records have been removed. If multiple actions are being posted for
multiple employees, the proof report is broken down by employee and then are grouped by the program
in which changes were made (Employee Master, Employee Job/Salary, etc.).
Scheduled Post
The scheduled post process provides the ability to setup a scheduled output-post process for all
approved actions up to a specific date (other setup options also exist, though this is the most common
use case).
25
After clicking Accept on the screen above, Munis will launch the schedule settings page where you can
define the timing and frequency of the process, the individuals to be notified and the printer or spool
directory to receive the reports produced by the process.
Refer to documentation available on the Knowledgebase for further details on use of the Munis
scheduler, including maintenance and administrative tasks. Once this process is defined, Munis will
automatically, in the background, at the specified time, using the defined parameters:
1. Look for any actions with an effective date less than or equal to (<=) “today’s” date (or the date
/ date range specified).
2. Produce the standard proof reports indicating all actions to be posted and the individual data
field changes (showing changed record specifics on what was changed, both Old and New) as well
as showing any records added or deleted.
26
3. Post all actions that have been fully approved and, if checklists are included, have any required
steps flagged as completed. Additional data checks are also performed before posting, any errors
that are generated will halt the process and produce an error report / log. Current error checking
and data validation checks that performed include: (Some of these checks are conditional based
on control file settings or other setup parameters):
a. Workflow Approval
b. Checklist Completion
c. Position Max FTE limits
d. Credential Validation
4. Hold back all records that are not fully approved or have incomplete checklists and provide you a
listing of those actions along with the reason they were not posted. The system will continue to
try and post those actions on subsequent runs and if these situations are resolved, will post them
as normal. Otherwise they’ll be held back and included on the error listings until such time as
those situations are resolved or those actions are deleted from the Pending Action file.
ACTIONS HISTORY
After actions are posted they potentially create history records (depending on the ‘Creates Actions
History’ checkbox). If the action creates history the data is stored and is accessible from the Actions
History program. This history program will allow for searching and basic reporting. Advanced reporting
options are available from the Actions History Reporting program.
Actions History Records
Actions History records are conditionally created and store basic information about the nature of the
action, basic pay information about the employee at the time of the action, and some detailed history
that allows access to the specific audited changes that took place during the posting of the action. In this
sense all the data relating to the changes made to live are tracked in actions history.
27
Information from the personnel action record is joined with information from the Employee Master
record to populate the main screen. The Employee Master data reflects all of the updated data values
that would have been modified during the action. The Change History section of the screen will show all
change packages that were applied to the Live data set. In this particular example only two changes were
applied, but the change packages can contain numerous entries from numerous tables. Clicking on these
rows will launch the Audit Inquiry program to help better understand the exact nature of the changes.
The Pay tab contains information about the employee’s primary base pay. (This can contain information
from the base pay that is not the employee’s primary job depending on personnel settings and the
changes that were made within the personnel action.)
The Civil Service and Other tabs contain information from the Civil Service tab of Employee Master, as
well as the Other data tab from personnel actions entry.
28
Actions History Reporting
Actions history reporting can be used to perform detailed reporting in a more robust manner. The
options that exist in this program make finding specific trends or generating employee history tracking
much simpler than attempting to find the data records in the actions history program. For a more
detailed explanation of the capabilities of this program the Munis Knowledgebase should provide ample
information.
29