[MU-HR-11-B]
Understanding Personnel Actions
Munis-Human Resources: Actions Entry
COURSE DESCRIPTION
The Personnel Action Entry features found within Munis provide you with the ability to enter
employee changes in a secure manner, allows for distributed approvals through workflow, permits
you the flexibility you need to enter changes without need to adhere to strict timelines tied to Payroll
processing and allows for efficient and effective reporting of changes made to employees based on a
number of reporting parameters. This session will provide a general overview of the process for users
who do not yet utilize the feature or use it in only a limited manner. It will also provide an
opportunity to seasoned users to explore additional options that are available.
WHY PERSONNEL ACTIONS?
There are a number of reasons why you should be utilizing Personnel Actions as the “method of
choice” for entry of employee data changes to your HRIS.
Security
First and foremost is Security. If you are entering new employee information or changes to
information to existing employees directly into the Employee Master file or to Job/Salary or
Deduction/Benefit records, you are making changes directly to LIVE data and impacting your payroll
process immediately. Changes made in this manner are not subject to oversight or review nor are
these changes subject to approval by authorized users prior to impacting payroll. From an auditing
standpoint there should be a procedure whereby data entry that impacts your payroll process should
be subject to review and approval prior to being posted into “Live” payroll data. You don’t allow
employees to purchase items using the City’s credit card without approval so why would you allow a
user to add an employee or given an employee a raise without the same thing? By utilizing Personnel
Actions Entry as the method for making changes to the employee data that directly impacts your
payroll you have the ability to implement strict security controls over the process.
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, you receive changes to employees
that don’t take effect for weeks (employee promotions, pay increases, changes to benefits). 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 you would need to wait to make that entry until the Payroll
department has completed processing on the last payroll that should use the OLD information. You
rarely have the opportunity to go ahead and get the information entered into the system when you
get the request. With Personnel Actions Entry, actions are entered with an effective date, thus
allowing you the opportunity to go ahead and get the information entered into the system now and
have the changes posted over on that effective date. From a workload standpoint this allows you to
spread the data entry tasks out rather than face a major crunch immediately prior to the new payroll
period.
Efficiency
How often do you experience delays or mistakes in payroll because a critical piece of information was
delayed or lost in transit from department to department? Wouldn’t it make more sense to have the
department or individual who first receives change request information to go ahead and enter it into
the system? Setup options, both procedural and functional, are available within Munis that can allow
departments to begin keying information for their employees directly into the system and notify you
in real time that those changes are entered and ready for review and approval.
Reporting and Tracking
A number of sites have requirements to provide periodic detailed Personnel Reporting to Council or
Board and often times those reports take a significant amount of time to collate and prepare. An
automatic feature of the posting process for Personnel Actions is the creation of an action history
record, including a snapshot of key data elements that are a part of any employee change. In
addition, the code values that are assigned to each personnel action (the “What” and “Why” of each
actin) can be structures in such a way that providing data to your School Board or City/County Council
regarding the number of New Hires, Terminations, Promotions/Demotions, etc., can be produced in a
matter of minutes rather than in a matter of hours or days. In fact, depending on the tools you use to
produce these reports, options can be provided such that real time snapshots of these statistics can
be provided to those end users in real time and “on-demand” potentially eliminating this task from
your list of responsibilities. The data is available immediately because of the method you use to make
these changes to your employee data.
SO HOW DO WE MAKE THIS HAPPEN?
Personnel Actions - Functional Basics
To help you better understand the process let’s first take a look at what happens in Munis when
Personnel Actions is utilized.
Understanding Personnel Actions 2
When you make changes to employee data using Employee Master Maintenance or any of the other
“direct menu access” maintenance options, you are making changes to “LIVE” data records. As we
discussed earlier, these “Live” data records are what other Munis Payroll/HR functionality use when
generating payroll or creating reports or other data inquiries. This is what the information for a
particular employee/record looks like NOW.
When you use Personnel Actions as your entry method, the first thing Munis does when creating a
Personnel Action is to make a copy of all of an employee’s LIVE data. Then when you proceed to
make the necessary changes you’re actually making changes to those record copies. Only after the
action has been posted do you see the changes you made within the action actually reflected in the
employee’s live data records.
Personnel Actions - Security
From a security standpoint the differences between Live and Pending are as follows:
Understanding Personnel Actions 3
HR-PR Role Definition > Category Access
The “Category Access” portion of the HR/PR Role Security definition is where you define whether a
user can make changes to an employee’s “LIVE” data record or whether that user must use Personnel
Actions to make any necessary changes to an employee profile within Munis. In the example shown
above, “ROB” can only look at the LIVE data records that impact the payroll process (Employee Master
or Employee Pay or Employee Deductions). If ROB is going to make any changes to those records, he
must do so through Personnel Actions.
You can carry this through to any and all users who will have access to employee data within Munis,
regardless of whether you plan to task them with any changes to employees. This is the screen where
you control WHAT a user with menu access to Employee Inquiry or any of the Centrals programs or
Webparts available for employee information access and at what level they’re able to access it. The
other two columns --Terminated Employees and Projections – control access from within the
Terminated Employee archive or the Salary/Benefits Projection module, neither of which will be
reviewed in this session.
An additional nugget to discuss here – the data access options available are as follows:

No Access – user cannot see anything within these data records

Update/Delete – user has full access and can see/touch anything in this data table

Hide SSN (Upd/Del) – user cannot see/maintain Employee Social Security Number but can
view/maintain all other data fields.

Inquiry Only – User can see all information from within this particular data record

Hide SSN (Inquiry) – User can see all information from within this particular data record
EXCEPT employee SSN.
When you are configuring your user roles do pay attention to what you intend that user to do and
whether or not that user should have access to an employee’s social security number.
MUNIS Tip – Only a user tasked with adding a brand new person to the system (New Hire) must have
access to the SSN field. If a user will be tasked only with updating information on an existing
employee, consider using one of the “HIDE SSN” options.
Understanding Personnel Actions 4
Personnel Actions – Setup
Before you can use Personnel Actions there is some code setup that must take place. There are three
tables that can be populated though only one of these is required. Guidelines for setup of each are
outlined here.
1 - PERSONNEL ACTIONS CODES (REQUIRED)
Understanding Personnel Actions 5
The Action Code values are required. These codes are 4 A/N codes meaning you can use of to 4 alphanumeric values when structuring your codes. In some sites, these are the only codes defined. The
other two options that we will discuss in a moment (Reason/Authorization and Supporting Action)
aren’t even used. This is a viable option but let’s discuss that further in a moment.
In addition to the action code values, which are your creation, there is also a Category value that
needs to be assigned which is a Munis system value. For every code you create you will need to
assign a category code. These values serve three purposes.
1. They let you classify your Personnel Action codes into logical categories (New Hire or Salary
change or Benefit change, etc.).
2. The category codes assigned here directly link to Workflow Business Rule types
3. The category code you assign will also, in some cases, cause the process to function a bit
differently.
To break this out a bit more fully:
Category
N
Description
New Hire
Business
Rule Type
PMN
Functional implication
Employee number/SS does NOT exist in
the system. Used for New Hires only. Also
causes display of “Condensed Pending
Master File” screens when entering a new
employee. This category is also used
automatically by the system if integration
from Applicant Processing functionality is
implemented
Understanding Personnel Actions 6
R
Rehire
PME
S
Salary
Change
PMS
E
B
Evaluation
Benefit
Change
PMW
PMB
I
Injury/Incident
PMI
O
Other
PMO
T
Termination
PMT
L
Leave
PML
A
V
Attendance
Civil Service
Validation
PMD
PMV
Employee number/SSN DOES exist in the
system but status for that employee is set
to “I-Inactive” or employee has been
moved to Terminated Employee database.
Used to “re-hire” or “reinstate” a terminated
employee or employee returning from
extended leave
Used for actions that impact employee
job/salary records. These include both
position/job change (transfer, demotion,
promotion) or Salary/Wage rate changes
(COLA, Increases, Decreases, assignment
of stipends, etc.).
Used for Evaluation actions
Used for Benefits changes. Primary
functional impact is that actions defined
with Category B cause Benefits History
records to be created rather than standard
actions history record. Data captured for
these actions are pulled from Employee
Benefits rather than Job/Salary
Used for actions that are caused by
employee accident/injury
Used for primarily actions that impact
employee demographic or contact data. In
other words, actions that don’t fall under
one of the other options
Used to process employee termination or
separation actions
Used to record actions that put an
employee out on extended leave (FMLA,
Military, Injury, etc.) Category L actions
require input into fields on the action
header record for Estimated Return date
and length of leave. In sites that do use
Seniority calculator feature, these values
on a Category L action can be used in
calculation of seniority for employees who
have utilized leave within the evaluation
period
You may not use all of these values. The most common ones typically include:

N – New Hire

S – Salary Change

B – Benefits Change
Understanding Personnel Actions 7

T – Termination

O – Other

L – Leave
Some of the others are optional and, to be quite honest, are rarely used.
When you’re creating these codes you also have the opportunity to pre-define some of the other
features in Munis that may or may not apply to a particular code type at your site.

Default Program – when a particular action type is initiated do you want the system to
automatically open up a particular Employee Data Maintenance screen? For a “Benefits”
action would it be helpful to have Munis automatically open the Employee Benefits screen?
For an Address or Date change action, would it make for a more efficient process if the
employee master screen to open automatically? Something to consider when defining your
codes. If the answer is Yes, then select the screen to open from the drop-down menu options
provided.

Default On-Board – if you’re using the On-Boarding feature in Munis, should a particular Onboarding protocol be applied to the employee being entered? Might make sense, particularly
for your new hire actions.

Survey Code – if you are using the Munis Survey function, should a survey record be created
and a link sent to the employee upon creation of this action? Some sites are using surveys for
Employee Termination/Separation actions, thus it might make sense to pre-define that
function at the action code level.
Please refer to other Personnel Action documentation on the Munis Knowledgebase for additional
information on these or the other features available within Personnel Action Code maintenance.
The ribbon menu option for Rapid Entry will be reviewed a bit later in this document.
2 - REASON/AUTHORIZATION CODES (OPTIONAL)
The Reason/Auth codes are optional so far as Munis is concerned. You can certainly build into your
Personnel Action Code schema sufficient detail so that the 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. For example, it is common in school districts to have different offices or departments
responsible for maintenance of Instructional and Administrative staff and for Support staff (Certified
vs Classified). If you utilize the Personnel Action code to distinguish between Certified and Classified
employees, then only the category value “N” will be used when defining your workflow business rules.
If, however, you choose to incorporate the Reason/Authorization codes into your structure you open
up the possibility of routing Certified New Hire actions to one office and Classified New Hire actions to
another.
Understanding Personnel Actions 8
In the example shown above, ALL new hires for location 135 will be routed to Ms. Spina for approval
at this step. If, however, Reason/Authorization codes were defined to stipulate the TYPE of new hire,
we could use this to stipulate that Mrs. Spina would be responsible for a certain portion of new hires
and that another user would be responsible for any other types.
Understanding Personnel Actions 9
To give you a better idea of the approach consider the following code setup option:
CURRENT
CODE
CATEGORY
REAS
01
02
03
04
05
06
18
25
15
17
10
11
14
26
27
38
50
51
52
53
54
59
70
71
72
73
74
79
22
32
37
39
10
10
10
10
10
10
20
20
20
25
25
25
25
25
25
25
40
40
40
40
40
40
50
50
50
50
50
50
60
60
60
60
N
N
N
N
N
N
S
S
S
S
S
S
S
S
S
S
T
T
T
T
T
T
L
L
L
L
L
L
O
O
O
O
10A
10B
10C
10D
10E
10F
20A
20B
20E
25B
25C
25D
25E
25F
25G
25H
40A
40B
40C
40D
40E
40F
50A
50B
50C
50D
50E
50F
60A
60D
60F
60G
85
70
70
B
B
70A
70B
70
B
70C
70
B
70D
70
B
70E
DESCRIPTION
FULL-TIME HIRE
PART-TIME HIRE
REHIRE - FULL-TIME
REHIRE - PART-TIME
TEMP/SEASONAL HIRE
REHIRE - TEMP-SEASONAL HIRE
PROMOTION
DEMOTION
POSITION RECLASSIFICATION
MERIT PAY
DEVELOPMENTAL PAY
PROBATION COMPLETE
TRANSFER WITH PAY CHANGE
TRANSFER NO PAY CHANGE
PAY & CLASSIFICATION STUDY
MISCELLANEOUS PAY CHANGE
RESIGNATION
DISMISSAL
RETIREMENT
DECEASED
REDUCTION IN FORCE
OTHER TERMINATE
MILITARY LEAVE
CIVIL LEAVE
FMLA
LEAVE WITH PAY
LEAVE NO/PAY
OTHER LEAVE
ADMINISTRATIVE CHANGE
NAME/ADDRESS CHANGE
EMPLOYMENT STATUS CHANGE
OTHER MISCELLANEOUS CHANGE
BENEFITS CHANGE - OPEN
ENROLLMENT
ADJUST BENEFITS
BENEFITS CHANGE - QUAL/MARITAL
STATUS
BENEFITS CHANGE - QUAL/CHILD
STATUS
BENEFITS CHANGE - SPOUSE JOB
CHANGE
In this schema you have about a half dozen personnel action codes being used. The codes define
basic action types (New Hire, Salary Change, Job/Position Change, etc.) The Reason/Authorization
codes then further clarify the type of new hire or salary change – the “Why” a change is being made.
Understanding Personnel Actions 10
That’s not to say that there are separate workflow business rules being defined for each of these
combinations but this does allow for the possibility to define it that way if your business practices
require it for any reason.
To define these codes, select the menu option for Miscellaneous Codes from the Personnel Actions
menu and then select AUTH-Action Reason/Authorization as your Miscellaneous Code type.
Codes defined for this field are up to 4 alpha-numeric characters in length and require both a short
and a long description. The Data field will not be populated for these code types.
3 – SUPPORTING ACTION
The Supporting Action field is completely optional and is not used in all sites. Those that do utilize it
use it 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. Sites that do use them seek additional
classification for certain action types primarily for reporting or internal statistical tracking purposes.
In addition, sites that utilize these codes typically will use them for some but not all action types.
Understanding Personnel Actions 11
To set these codes up you can 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.
These codes are also up to 4 Character A/N values and require both a short and a long description.
The Data field is not populated for these code types.
As an example of where these codes might be found beneficial is for a Benefit Change that is done as
a result of a Qualifying Life Event (QLE). One option might be:

Code - 70 – Benefits Change

Auth – 70Q – Qualifying Life Event

Supp – 70M – Marriage
WORKFLOW BUSINESS RULES
Once you have your coding schema laid out and defined through Personnel Action Codes,
Reason/Authorization Codes and Supporting Action codes, the next step is to define your Workflow
Business Rules. As a refresher, the Personnel Action Process is as follows:
Step 1:
Start your action
Step 2:
Make your changes to employee data records
Step 3:
Post your action
However, one of the primary reasons for incorporating Personnel Actions Entry into your procedures
is to include authorized approval to changes made to your employees. While you will be defining an
effective date into the action you are creating, nothing is going to magically happen on that data to
post that pending action over into your live dataset. Someone is going to have to push the
Output/Post button to make that happen. An alternative to this is to set the Actions Post process to
happen regularly through use of the Munis Scheduler utility. Either way, with Workflow approvals in
place, no matter which option you choose to use for moving pending actions over to “LIVE” – this
process will not post actions that have not been approved prior to the posting operation. This is
where you get to insert the controls that are so necessary to your operations.
Understanding Personnel Actions 12
Workflow business rules are defined at two levels for Personnel Actions
1. At the Personnel Action Category level. The business rule type definitions are indicated on
the chart found earlier in this document. Each Personnel Action category value has a
corresponding Workflow Business Rule type defined for it.
2. At the Reason/Authorization level. When defining Workflow Business Rules you have the
option to stipulate, for example, that PMN – New Hire Actions defined with
Reason/Authorization code value X goes to person 1 and those with code value Y goes to
person 2. This is optional and even if you use this feature for some action types you may not
use it for all.
In addition, for each Workflow Business rule you define you also have the option to stipulate different
notification/approval chains based on Location or GL Segment or Job Class or any of a number of
other options that are available.
This document will not go into great detail on Workflow Business Rule setup. For that information
please refer to any number of great documents available on the KB that are designed specifically for
this purpose. As a summary, however, please consider the following:
1. If workflow is to be used for a particular action type/category, at least one rule must exist for
that category value.
Understanding Personnel Actions 13
2. Workflow business rules can be defined so that actions of a particularly type/category for all
employees in a particular location or ORG or GL Segment or all employees with a particular
Job Class or Job Class range can go to one person and those with a different location go to
another. If that is what you want then a rule needs to be created using that particular value.
3. The fields for these options are optional. If any/all are left blank then that is telling the
system that “All New Hires” or “All Category S actions” go to a particular individual or group of
individuals.
4. Business Rules can have Approvers defined as specific Workflow Approvers (as defined within
the Workflow Approver table by Munis User ID) or as specific User Roles.
5. Business Rules can be defined as Notification Only should you wish to have someone notified
that a particular action has been created but don’t require their input or approval. Say, for
example, you wish to have IT notified of a new hire but you really don’t need them to approve
the action. One caveat here, though. If a notification is sent and the action is fully approved
and posted before the individual notified clicks the notification to review the action, there is
the possibility that the record will no longer be available for viewing. The notification being
sent contains a link to the pending action and if that pending has been posted it won’t be
there anymore.
USING PERSONNEL ACTIONS
Menu Option – Actions Entry
OK – so we’ve got the codes setup and the business rules established. Now what?
Take the option for Actions Entry found on the Personnel Actions menu
Understanding Personnel Actions 14
(Munis > Human Resources/Payroll > Personnel Actions > Actions Entry)
Take the option to Add a record and provide the following information:
1. Employee Number – whose record is being changed? You can use the field help option to
select the employee from a list or simply enter the employee number, if known. If this action
is for a New Hire, simply <tab> through the field and let Munis assign the next available
employee number.
2. Effective Date – when should this action take effect? Primarily this date is used to specify
when this pending action should be posted over to the live database but in most cases that
will also be the date on which the change should be made. For example, first day of
employment, first day in new position, first day at new pay rate, etc.
3. What kind of action is this? Use the dropdown menus provided to select the codes
appropriate for the
a. Action Code
b. Reason/Authorization (optional)
c. Supporting Action (optional)
Primarily this is being used to describe both for now and for later reporting the kind of action
you’re entering. It’s the “What” and “Why” for the action and why the change is being made.
Additional fields may be populated automatically depending on how the Action Code you selected is
defined (On-Boarding Code for example) though it may also be manually populated by you if your
procedures direct you to do so. As with other fields, simply select the appropriate option from the
dropdown menu provided.
The Comment field may also be populated if you wish with a short description of the particulars of
this action or as a way to communicate to the approver or the next user “down the line” of something
to change or to pay attention to. You are limited here – 50 or 60 characters depending on your
current release level. If additional space is needed, click the
button found on
the main tab of the actions entry screen. This option can be used to enter unlimited text as needed
for the action. Your own internal procedures should guide what information is entered here and the
method to be used.
Click Accept to finalize the entry.
Understanding Personnel Actions 15
Some action types may require entry on the Other tab though this is 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 and you won’t need to change that. Evaluation Score and Pay Off
amount and 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. Sites that utilize the Seniority Calculator feature
in Munis should pay attention to the Seniority Impact flag. 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. For sites that don’t
utilize this feature, you will still be required to input 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 typically a pretty good idea.
Once you’ve completed entry on these screens and clicked the Accept button, depending on how
you’ve defined the Personnel Action code selected you may directed to particular screens within the
Understanding Personnel Actions 16
employee profile automatically. If not, use the Detail option from your ribbon menu to navigate the
Employee data screen(s) in which changes will be made. The procedures you use from this point are
identical to those you use today. There is no difference in data entry methodology between “LIVE”
data entry and entry within Personnel Actions.
The fields, the data and the procedures are identical. The only difference is that when you make
changes in “LIVE” Employee Master you’re updating “LIVE” data records. In Personnel Actions, the
records your changing are copies of the original.
Understanding Personnel Actions 17
“Wizards” or “Centrals”
There is an additional option available to users at version 9, 10 and above that are worth discussing.
While the functionality is largely the same the user interface might be found to be a bit more user
friendly and are worth looking at, particularly if the idea of distributing the employee maintenance
workload out to the department or campus level.
PERSONNEL ACTIONS “WIZARDS”
Found on the HR/Payroll option on the Centrals Menu, these “Wizards” can be used by departments
to initiate actions that normally would be delivered the HR department for entry. They are limited in
scope and not all action types can be entered using these programs.
Employee Changes
Let’s take a look at one of these. Employee Changes can be used to make basic data entry changes to
the employee’s master record; things like Address or Contact or Phone number, for example.
To start the process, select the option from the menu.
Search for the employee whose data you wish to change by entering what you know in the field
provided. This could be Employee Number or his/her last name.
Understanding Personnel Actions 18
Once entered, click Go and Munis will search for the appropriate records. Returned records will
display in the list as shown above. Select the employee whose information needs to be changed and
click the arrow to the right of the screen to proceed to the next step.
The data elements that may be changed are restricted by both the option that you select from the
centrals menu and your security profile. In this instance, Employee Changes only allows changes to
be made to the Employee Master record.
The options available to you are shown on the left and correspond to the folder tabs you see on the
Employee Master record. Click the tab on which you wish to make your changes and enter the
changed values in the fields displayed.
In the Action Effective Date field enter the date this change should be made effective and in the
Action Code field select the action code to be assigned to this. As you can tell, it is a bit reversed from
normal actions entry – make the data changes first and enter the effective date and action code
second. But it makes sense and is something quite easy to train to end users.
Understanding Personnel Actions 19
In the case of the Employee Changes wizard, the codes that display are those defined as category O –
Other. No Job Changes or New Hires or Termination options are available. This is by design.
Once you’ve completed entry on this screen, click the arrow to the right of the screen to proceed.
Munis will then display a screen showing you what you’ve changed and allowing you a chance to
review it and possibly correct it before submitting it for processing. At any stage of this you can use
the arrow on the left side of the screen to go back to your previous step to make changes.
You also have the option to scrap the record entirely and start from scratch by clicking the “Restart
Wizard” button found at the bottom of each of these screens.
Munis also displays a status bar on each screen to remind you of just where you are in the process in
case you get lost!
Once you’re satisfied that the changes are correct, click Save Employee Changes at the bottom.
Munis will then process the record and give you the option to release the changes for workflow
review and approval.
Understanding Personnel Actions 20
Once released, Munis will notify you that the process was successful
Additional options are available to View Pending Actions allowing you to see any additional actions
that have been created for this employee or to Restart Wizard to allow to continue your data entry
work with the next Employee Change action.
Similar processes are available to utilize these wizards for entry of new employee data or employee
terminations.
OUTPUT/POST
As we’ve discussed through this process, no changes made through 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. Be aware,
however, that if any record within your find set has not yet been approved (Status is anything other
than Y-Approved) then no records in your find set will post. You will get the proof report showing you
what data elements will be changed if/when the approval to post is given but you will then be given
an error message indicating that “one or more actions have not been approved” and none of the
items in your find set will post.
Understanding Personnel Actions 21
It is an easy issue to get around. Either browse through the records in your find-set and see what
items need to be approved and address each of them that way or refine your search criteria to include
Status = Y-Approved so that only approved items are included in your find set. Then repeat the
Output-Post operation again and all items will then be posted. You still need to address those
unapproved items, however!
Another option available, if you’re using the Scheduler feature within Munis, is to assign the posting
of Personnel Actions to the scheduler. The system will still only post Approved actions (and those
with completed checklists if you’re using that feature as well) but it will 1) not hang up because there
are other “Unapproved” or “Uncompleted” items in the find set and 2) provide you with a list of
actions that might have been posted but weren’t for the reasons given.
Usually sites will schedule this process to run late at night or early in the morning and define it to
process all items with effective dates up to and including “Today”.
To define this, select the Schedule Post option found in your ribbon menu.
Click Define and select the following options:
Execute this process “At a schedule time” and then select All to Date as the additional parameter.
You can also use additional options but the best method to use to catch all unposted actions and
process them on or as closely following their effective date as possible is the All to Date option.
Understanding Personnel Actions 22
The screen also gives you the ability to define this for particular actions codes or categories but the
most common approach is to have the system run this daily for all actions at the same time.
Once you’ve made your selections on the screen above, click Accept. Munis will then take you to the
schedule definition 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 KB for further details on use of the Munis
scheduler, including maintenance and administrative tasks or discuss with your site’s system
administrator for any site-specific information you might have. Once this process is defined Munis will
automatically, in the background,
1. Look for any actions with an effective date less than or equal to (<=) “today’s” date
2. Produce the standard proof reports indicating all actions posted and the individual data fields
changed (showing, for changed records, specifics on what was changed, both Old and New) or
any records added or deleted
3. Post all actions that have been fully approved and, if checklists are included, have any
required steps flagged as completed
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.
Understanding Personnel Actions 23
REPORTING
Finally, to reporting! One nice by-product of the Personnel Action Entry method is that, in addition to
producing a proof report at the time an action is posted, the system also creates an Actions History
Record which includes details of the action (Effective Date, Action Code(s), comments) and a
snapshot of the employee’s data (primarily Position/Pay information) as it existed at the time a
particular action was posted.
There are a couple of things you need to do to insure that these history records are created.
Action Code
If you want an Actions History record to be created for particular action types/codes, make sure to
check the Actions History Default box on the Actions Code screen for this record.
Pay Type Codes
There is also a check box on the Pay Type master that will need to checked if changes to a particular
pay code should be included. This primarily impacts an .xml file that can be created as part of this
process but it doesn’t hurt to check the option for each pay code you want to include as part of this
action history process as well.
Understanding Personnel Actions 24
Accessing Actions History Records
There are a number of ways to access these Actions History Records.
One way is through the Personnel Actions Menu. The two options here take you to the same data
records with one major difference:

Actions History Inquiry – is an “Inquiry Only” program that lets the user Look but not Touch.
This is the best option to give to most users who have need of this data.

Actions History – is a file maintenance program and allows the user with access to this option
to make changes to Actions History records or to add or delete records as needed.
Now why in the world would anyone want to make changes to Actions History records created by this
process? Perhaps an incorrect code combination was used in classifying the type of change made.
Maybe a date was mis-keyed. Anything is possible but it’s nice to know that changes can be made
when necessary. That said, you want to be careful in who you grant access to the maintenance
option. Changes made to this file can be audited but as these changes don’t impact actual employee
data, particularly data used for payroll, there is no workflow associated with it.
The more common access avenue to these records would be the “Inquiry Only” option. From within
here searches can be performed using any field available

Changes within a particular date range

All changes for a particular category or action code
Understanding Personnel Actions 25

Changes entered by a particular user or on a particular date or within a particular date range.
In addition to the basic information associated with a particular action, this record also provides
access to the details of what records/fields were changed. The system displays that information in the
Change History section of the screen. The Ribbon Menu option for History Detail will also take you to
the Munis Audit records created by this action to allow you to view all tables/fields changed including
“From/To” values for the changes made. In addition, you will have access to the workflow approval
chain (who approved the action) as well as any notes or checklists that were included as part of this
action. Basically a full view of all data included with any individual action.
The data in this file is also available for export to Excel which can then give you an opportunity to
Group or Sort data for use in preparing any statistical analysis or Board/Council reports you may need
to create. The data is also available for use in any ad-hoc reports you may wish to create using your
report writer program to facilitate this process.
Understanding Personnel Actions 26
EMPLOYEE DETAIL
The Actions History record is also available, in inquiry form, using the Detail Menu from within
Employee Inquiry or Employee Master. Great way to look at an employee’s change history from
within the employee profile itself.
Conclusion
A “Brief” overview of the Personnel Actions process is difficult to do in the hour that we have been
given. There are a number of options available that we did not have time to cover, including:

Checklists

Rapid Entry

On-boarding

Personnel Action forms

Defining Procedures for action types

Use of Tyler Content Manager

Integration with Applicant Processing
It is my hope, however, that this session has given you an idea of the functionality and opened the
possibility of process changes that can serve to make your HR Management procedures more efficient
and more secure.
With Personnel Actions you now have the possibility of opening up Employee Maintenance tasks
beyond the core Human Resources department allowing you to spend valuable time on more mission
critical tasks.
We at Tyler remain committed to providing you the support, training and consulting services you may
need to expand use of this valuable tool within your organization.
Understanding Personnel Actions 27