Attendance overview

Attendance automates the process of tracking and enforcing the types of policies that might typically be found in an employee handbook. Missing a punch, being absent, punching in or out too early or too late, or consistently taking longer breaks than allowed are all common examples of the types of employee policies Attendance can be configured to support.

Attendance works with rules and policies. For example, if an employee is absent three times in a month, your policy might state such an employee is then on probation. A fourth absence in that time period could result in a final warning, and a fifth in termination. This product automates the enforcement of such rules in a very configurable way.

Attendance input

To perform its work, Attendance consumes data from other parts of the suite ecosystem--primarily Timekeeping and especially the Totalizer, tracking data such as:

Attendance consumesInput to/output from Totalizer
ExceptionsOutput
Pay Code EditsInput
Timecard TotalsOutput
Scheduled TotalsOutput
CommentsInput

As far as Attendance is concerned, however, the whole table above is input:

Attendance consumesInput to/output from Attendance
ExceptionsInput
Pay Code EditsInput
Timecard TotalsInput
Scheduled TotalsInput
CommentsInput

Consider Exceptions, which are the most prominent input for Attendance. Exceptions include events such as:

  • missed punch
  • absent
  • late in punch
  • early out punch
  • long break punch

Exceptions begin life as configurable elements in Timekeeping and can be tailored to your organization's needs. The Totalizer outputs Exceptions as a specific category of output.

This data flows in one direction only--from the Totalizer to Attendance. Attendance isn't responsible for this data, but it does consume the data in a variety of ways.

How Attendance processes input

In this overview we examine several scenarios in order to understand how Attendance transforms data Timekeeping already collects into a powerful, automated system that helps enforce many of your company's hourly employee policies. We will also look at the main tools Attendance uses to perform its job:

Events

Attendance Events determine what data from Timekeeping is significant to your organization's policies. Each Event maps to one of the things Attendance consumes from Timekeeping. Events are input for the series of rules enforced by all active policies.

This degree of configurability allows your company to specify which Timekeeping events to consider as part of policy enforcement and which to ignore.

Policies and Rules

Within Attendance are a number of policy types. Each policy type consists of a set of rules. Each rule evaluates as true or false regardless of the type of policy in which each rule appears.

Attendance Policies are contained within Attendance Profiles. Attendance Profiles are assigned to individual employees.

Policy Types:

  • Discipline
  • Total Balance
  • Perfect Attendance
  • Formula
  • Previous Action

Policy execution

Consider a Total Balance policy which defines and enforces thresholds. Since almost all policies are a collection of ordered rules which are typically executed in the order in which they appear, ordering is important--in the case of a Total Balance policy, the policy looks at the highest or most severe rules to execute against an employee based on the thresholds it defines.

If a rule evaluates true, a configurable consequence occurs. This is also defined in the rule. The consequence is an Attendance Action.

Discipline policies

Discipline policies can be configured to perform different functions. The most common use is to assign points to infractions. For example:

Infraction typesPoint assignments
Event A5 points
Event B3 points
Event C2 points

In this example, the policy is not concerned with the reaching of thresholds. However, such a policy can be configured to enforce thresholds.

More rarely, some organizations count infractions using a discipline policy without assigning weights. For example, if an employee reaches 3 absences during a time period, a consequence is incurred. This type of policy is very simple to configure, as you only need one policy. However, it is not very useful because it doesn't weight different types of events. As a result, it can only look at one kind of event per policy. You must configure a policy based on absences and another for missed punches, and so forth.

In general, it is more common and more useful to develop a weighted policy that considers all infractions in aggregate.

Total Balance policies

A Total Balance policy generally defines and enforces point balance thresholds.

Perfect Attendance policies

A Perfect Attendance policy tracks employees whose behavior remains "perfect"--based on your organization's configurable definition of "perfect"--for a defined length of time in order to qualify for a reward. Refer to Perfect Attendance for more information.

Formula policies

A Formula policy performs math (typically a ratio) on two point balances in order to produce another type of trackable balance.

An organization often has multiple discipline policies that feed different point balances. A formula policy compares two of these balances and produces another balance, which is then examined by a Total Balance policy.

Previous Action policies

A Previous Action policy monitors whether or not there has been a previous Action. An organization can chain Actions into something that causes a consequence for an employee. For example, if an employee receives 3 verbal warnings within a year, that can be configured to result in a consequence.

Actions

Actions are a configured list of entities that each represent a consequence such as a verbal warning, termination, and so on. Actions are an output of the Attendance Processor. Action Definition refers to configuration side, Action Transaction refers to the output of the Attendance Processor.

Actions in Attendance are symbolic. They represent an informational flag to a human being informing him or her that they need to go do something, such as a manager delivering a verbal warning to an employee.

Discipline Levels

To understand Discipline Levels, consider an employee who has passed one threshold and received a verbal warning and then within the same trailing period passed a second threshold which places that employee on probation. Once in probation, a different set of rules apply to that employee's behavior. These different sets of rules are called Discipline Levels in the Attendance domain.

Note: A trailing period, also known as a rolling period, is defined as an ongoing "30 days back" or "15 days back," and so on. Trailing periods are defined in a discipline policy.

When an employee moves from one discipline level to another, such as from "normal" to "probation," balances may reset to zero, rules may change, the employee is under a different, usually more strict behavior policy, and thresholds for further escalation are usually reduced from the normal level.

Perfect Attendance

To understand Perfect Attendance, first realize that "perfect" does not imply the employee did absolutely nothing wrong. Your company defines what constitutes a "perfect," or acceptably good, standard of behavior. Based on your configurable definition of acceptably good, an employee can remain in this state through some defined length of time in order to qualify for a reward.

As Discipline Levels measure violations of acceptable behavior, Perfect Attendance provides a way to measure and reward an employee's good behavior.

Points and Point Balances

Employee handbook policies are often written based on a point system where different infractions have different point weights. In Attendance, these points are tracked using a point balance for each employee.

An example of how points and point balances work, consider an employee policy that states: if at any time during the last 30 days an employee's point balance reaches 20, that employee incurs a verbal warning. The company might also track early outs and long breaks as being worth 2 points each, while an absence is worth 10 points.

Note: Comments are used heavily in Attendance to help define at a very granular level what exactly happened with a given employee or situation. As an illustration, consider the following example. You're tracking late in punch as an infraction. Your late in is defined as "more than 15 minutes late." From a policy perspective in Attendance, all of these 15-minute-late exceptions are not the same. For example, if an employee calls in and warns the manager an hour before, or did not call at all, or called after her shift was scheduled to begin--all of those situations may have different consequences or result in different point balances. A manager can attach a comment to an exception, and this comment can modify the exception to determine its weight. Note that comments are data or pre-selected text, not freeform comment fields.

The Attendance Processor

The Attendance Processor is where all of these elements come together. The Processor is responsible for performing the Timekeeping data extraction as well as enforcing the rules that are defined within Attendance Policies.

Attendance Processor workflow

Unlike the Totalizer in Timekeeping, which is run as often as necessary to provide up-to-the-moment accurate data, the Attendance Processor is run at defined points in an organization's workflow.

Because the Attendance Processor is primarily fed Timecard data, the typical workflow on the Attendance side is:

  1. A manager corrects Timecard data to reflect the reality of what happened during a period.

  2. The manager runs the Attendance Processor.

If the Processor ran every time totals changed, it would create many false alarms. This workflow allows managers to prepare the Timecard first.

Note: When the Attendance Processor is run, the Totalizer is always run too.

Running the Attendance Processor

There are several ways to run the Attendance Processor.

  1. For a Single Employee If you are looking at an employee's details in the Attendance interface, you can select an option to run the Processor for that employee. As an API call, this operation is synchronous--it will not return until the data has been computed.

  2. For Multiple Employees As an API call, this operation is asynchronous by definition, even if group is defined as just one employee.

    a. Single Instance As a user action in the UI. Select a set from the landing page or a Dataview. Select the Apply Rules action. This scenario is less common.

    b. Recurring Instances You can schedule the Processor to run on a regular interval in Event Manager. This scenario is more common.