Initial Setup

Getting Started

When considering your initial setup of the Entry-Exit application, it can be daunting to look at the blank page and think of how to organize all your onboarding and offboarding tasks. The following tips can help you decide how to approach your setup.

The best place to start is with your current onboarding and offboarding practices. Different units have different levels of organization applied to the process. Taking a good look at your existing process and thinking carefully about the steps that are taken and who does them will help you think about how to use the application.

If you currently have lists of tasks documented, you’ve got a good head start. There are also university resources at these locations:

• Supervisor's Guide: Welcoming and Orienting Employees
• Exit Procedures for Staff

If you currently send out a “kickoff” email, alerting people that an onboarding or offboarding event is occurring, then that is also a good place to start. Look at the recipients of the email and think about the reason that each person is being notified. Look at the body of the email and think about what it is you’re telling people, and how that information is organized. 

You might organize your information in a worksheet like the following.

When you list the information this way, many things become apparent. It can help to identify your tasks by linking up the onboarding task with the corresponding offboarding task. Listing which Work Groups are accountable can help to identify you Sections. By seeing which Worker columns get checks and which don’t, you can begin to decide how you want to set up your templates based on commonality.

Defining Your Sections

The first thing you need to do when setting up the Entry-Exit application is to decide on your Sections. This concept is probably not part of your current practice, and it can be difficult to envision the best way to set them up. At a minimum, you could just create one Section, and throw all your tasks into it. That is a perfectly viable approach, but you will probably find that you need a more granular level of organization.

The intent of “Sections” is that they should correspond to the work teams that will be performing tasks. The primary responsibility of “Section Administrators” (that is, work team leads) is to define all the tasks that must be performed within their sphere of responsibility for your onboarding and offboarding scenarios. Whoever makes the call as to what tasks should be performed should have a Section of their own to manage. 

The determination of what tasks must be performed usually comes from a fairly high level in the organization, which on the surface makes it look like the one-section solution is best, so that control over the tasks lists can be centralized. However, it is likely that the workers who are performing the tasks need to identify them at a more detailed level than the high-level people want to concern themselves with. This supports the notion that each work group should have its own Section. For example, central administration might require that new workers be granted access to the department servers, and that the access must be revoked for departing workers, but not have all the details of what that means. You can create a Section for “Security Authorizations” and assign the Section Administrator role to the manager of the team that actually provisions and deprovisions access. That person can then enter individual tasks to itemize the things to which the workers will be granted access.

Defining Your Tasklist Templates

The next step is to determine how to organize your Tasks into Tasklist Templates. This is probably something that you’re doing already, just not thinking of it in such a structured way. 

A Tasklist Template is a way to bundle tasks together so that they can be included in an HR Event as a group; you just need to figure out what those logical bundles are. At a bare minimum you would have two Tasklist Templates: one for onboarding, another for offboarding. As with Sections, when you look at the details of the positions that are being filled or vacated, you will probably want to break it down further.

The best way to start is to look at the tasks that are performed uniformly for any onboarding or offboarding irrespective of the position. Those would be your default Tasklist Templates. 

Then consider what additional tasks must be performed, and under what circumstances. For onboarding, this will probably come down to the type of worker who is coming in. You might perform tasks for a permanent position that you wouldn’t for a temp, and vice versa, or tasks for part-time vs. full-time, or things you might do for an intern that you wouldn’t do for anyone else. For offboarding, tasks for retirees are not the same as for someone who is resigning their position.

When you initiate an Event in the application, you will “layer” these templates. You will select the default template that applies to everyone, and then any others that apply to the specifics of the Event you’re initiating. 

Defining Tasks - Use Assignee Groups

Once you’ve identified all your tasks, the process of setting them up in the Entry-Exit application is pretty straightforward. One highly-recommended practice is alwaysto use Assignee Groups. 

When you define the Tasks within a Tasklist Template, each one needs to have at least one default assignee. Typically you have multiple default assignees so that there is always backup. The Assignee Group feature was created so that you can put these assignees into a group and assign that to the task to save you the effort of adding them individually on each and every Task. However the added benefit is that when people change roles, you only need to change the group membership, and that will propagate out to all the Tasks to which that group is assigned. 

Leverage Existing Task Management Utilities

When you dig more deeply into what tasks are performed during onboarding and offboarding events, you may find that some teams are currently managing their work in other applications, for example Workday workflows or TDX workflows. You do not want to recreate all that detail and specificity in the Entry-Exit application. 

The best way to approach it is to first identify what these things are, how they are initiated, and who is responsible for initiating them. Typically you would have a Task in your Tasklist Template(s) instructing the person to initiate the appropriate action in the external system. If the initiation process involves submitting a form, you can put a link to the form right in the Task Description. 

The person who accepts the Entry-Exit task and initiates the process in the external system will then need to monitor the progress externally and mark the Entry-Exit task as complete when it is marked complete in the external system. This will create a little additional effort, and will mitigate the visibility from within the Entry-Exit application, but there’s really no way around it.

Naming Conventions

As you set up the application, you will need to name things. Sections, Tasklist Templates, Assignee Groups, and Events all have names. Be thoughtful how you chose these names, and establish naming conventions where possible.

One tip is to keep your names relatively short. These names will appear in other places, such as dropdown lists. Making the names too long can get unwieldy in a number of ways.

Keep your Tasklist Template names unique across Sections. It is possible to have identical Tasklist Template names in different Sections. The Section Admins themselves will never know, because they only see their own Section, but when the Initiator goes to initiate an event, they will see all the Tasklist Templates for the Unit, and they may get confused if names are the same.

Ongoing Use

This section provides tips and techniques as you use the system as part of your normal business processes.

Initiating Events

Be thoughtful when you choose your Event Title. It will appear in many places, including the Events dashboard and all automated notifications that go out. Titles appear in the format <worker name> - <event title>. It’s best to keep the Event Title simple. For example,

• John Doe - New Hire
• Jane Doe - New Temp
• Jack Sprat - Transfer Out
• James Madison - Retirement

The application brings in some information from Workday. If your assignees need information that is not stored directly in the application, you can note it anecdotally in the Event Comments. These comments will be visible to anyone who has access to the Event on the Events dashboard, as well as Assignees who are performing tasks for that Event.

Sometimes you need to perform tasks well in advance of the actual onboarding event. For example, the department has gotten approval for a new line, and equipment must be ordered well in advance, even if the hiring process has only begun. In this case, you can initiate two different events for the same position, one now for the early setup, and another later once the candidate has accepted the offer. This will require that you define your Tasklist Templates accordingly, so that those early tasks can be selected for the early Event.

It also might be the case that you need to initiate an Event in Entry-Exit before the position has been set up in Workday. This will preclude you from using the Workday integration to pull in position information for your Event. If that is the case, select the Worker Type “Other Worker” and enter the position information manually. Hiring Supervisor is the only required field. 

You might want to launch an Event in Entry-Exit without knowing the exact Effective Date, yet it’s a required field when initiating the event. The best practice is to select the date that you (and/or the Hiring Supervisor) want the most timely tasks to be completed.

If you’re onboarding or offboarding batches of workers, for example SCL with seasonal food service staff, or AAD with reunion weekend workers, the application currently does not support that. You may want to track the batch externally, in a spreadsheet or other tool.

Events in Progress

Once you dispatch an Event, Assignees will begin accepting and performing tasks, but sometimes life happens and you need to make changes.
Suppose an Assignee has accepted a task, but later determines that they won’t be able to complete it. They must go back and decline the task, which will make it available to other Assignees to accept.

Suppose an Assignee has accepted a task, but unexpectedly becomes unavailable. The Initiator should go into the Initiator page and edit the tasks, removing that person as an Assignee. This will allow other Assignee(s) to accept the task. This can also be done if for any other reason you want someone other than the acceptee to perform the task, and don’t want to wait for them to go back and decline it.

It is possible to delete an Event after it has been dispatched and tasks have been accepted and/or completed. This would presumably only be done in extreme circumstances. If the Event is deleted, all history will be deleted along with it. For that reason it is advised that you download the audit log before deleting so that you can preserve a record of the activity that was performed.

General Upkeep

In order to ensure that your Tasklist Templates and lists of Tasks are current and up to date in a changing world, it is recommended that your Unit have periodic reviews to revisit your setup and make changes as needed.