Long guide: Staff allocation

This long guide aims to cover various staff allocation scenarios that may occur in the real world and explains how to replicate them in your Glide system.

There should be 2 main objectives when configuring staff allocation in a workflow:

Any Glide user with responsibility for (or just interest in) any job should be linked to that job (i.e. occupy a job position). Doing so provides two key benefits:
1. Firstly users can then filter dashboard widgets to the linked view to see their portfolio / their clients / their jobs etc.
2. Secondly automatic changes in job holder, automated e-mails/SMS and automated alerts can all be set to use job positions meaning once completed you can do a lot with them.
The Glide user currently working on a job should be the job holder. This means the job will appear in their jobs held widget, essentially a to-do list.

This article covers the following common scenarios:

Managerial roles:
1. Partners / Directors / Managers / Practice Owners etc -> in client management roles.
2. Partners / Directors / Managers / Practice Owners etc -> in service management roles.
Field worker roles:
1. Same person always does the [e.g.] Accounts.
2. Jobs allocated based on available staff.
3. Staff take jobs from a pool list.
4. A mixture of the above.
Administration roles:
1. Specific user always does this/that [a step in a workflow].
2. Working as an admin team (covers any team working scenario).
Setting the job holder.
Quirks

1a) Partners / Directors / Managers / Practice owners etc --> in client management roles:

Often (but not always) there are Glide users who have responsibility for a group of clients and are therefore interested in all of the workflows associated with those clients. For example a practice owner may have no direct involvement in a client's VAT return but, given his/her responsibility for the overall client relationship, would wish to see the VAT jobs on the Glide dashboard. If you have positions such as these then you would benefit from the using the partner and/or manager fields.

All Glide systems have a client field called Partner and a client field called Manager - they automatically link to job positions on all workflow systems (described in more detail here).

A few points to consider here:

If these fields generally work except that the relevant users have no interest in a small number of workflows (e.g. partners take no part in payroll) then you can de-link the positions from any workflow system (this is a single global setting on each workflow system, not 'per partner').
You can create more custom client fields that act in an identical way, for example if you also have a 3rd tier of client management such as an assistant manager, then you can set this up identically. To create the new client field to hold the allocation follow these steps (field type = staff) and then you would link this field to a position on every workflow system.
If the responsibilities of your managerial staff are linked to services as opposed to clients (e.g. Bob is responsible for all management accounts but has no interest in any other work) then do not use the partner and manager fields. This will result in too many jobs being included on user dashboards.

1b) Partners / Directors / Managers etc --> in service management roles:

This is the opposite of the above. Here a manager (for example) in a practice may be solely in charge of say VAT returns and management accounts but has no wider responsibilities to the clients he/she manages. They would not wish to see jobs for say Accounts and payroll on their dashboards.

Here you need to set up your own custom client field(s) (follow these steps, field type = staff) so that you can enter a team member into this new position for each relevant client. For example you may set up a position called Business Services manager which you plan to link to VAT returns and Management Accounts.

Bear in mind that you can have as many fields as you need and that one field can serve any number of job positions on any number of workflow systems. For example the single field Business Services Manager may provide the manager for both VAT and Management Accounts jobs; however, if some clients have a different manager for VAT and Management Accounts then you would need two client fields (even if they were occupied by the same user for all other clients).

Setting up field(s) on your client record is step 1; however, it does not achieve either of the 2 key objectives noted at the outset of this article. We need these users to automatically be linked to jobs. This happens automatically for the partner/manager fields but here we are deciding which workflow system(s) the field is linked to.

To achieve this you need to set up a job position on the relevant workflow system(s), to do this follow the steps here. You will need to do both steps 1 and 2. The crucial step is to set the initial value on the job field, you will choose your newly created client field (e.g. Business Services Manager) and when jobs are created the system will look to the client field to set the initial occupant of this position.

2a) Same person always does the [e.g] Accounts:

When deciding which member of the team will complete a particular job (e.g. the Accounts for XYZ Ltd to 30 June 2018) the most common variation we see in Glide is between the situation where the same person will typically do the job from year to year (month to month, week to week etc) v the situation where a job is allocated at some point after it has been created in Glide, often when the staff planner is being completed or when the information is available, to whomever is available and the most capable of completing the task.

This scenario covers the initial option where by the same team member will do the job each year.

To set this up you do exactly the same as described in scenario 1b (service orientated managerial roles). For example you might do the following:

Create a client field called Regular preparer - Management Accounts. This is a popular approach and accordingly all Glide templates have a client field named in this way for every workflow system. Of course you do not need to use them and indeed you can just use them on some clients and not others (this works fine as explained in scenario 2c). One common change you might make is to reduce the number of client fields. For example you might know that the same person always does Payroll and Pension workflows meaning you only need 1 client field.
Create a job position called Preparer. Again every Glide template has this job position already active and they are set to get their initial value from the Regular preparer field on the same workflow system.

With this setup you simply need to allocate the responsibilities for each workflow at a client level and the jobs will automatically be allocated. Of course you can change a job allocation at any time once it has created. Bear in mind that changing the client field will automatically update all active jobs.

2b) Jobs allocated based on available staff:

This covers job allocation scenarios where you do not use a client field because there is no permanent association between the user completing a job and a client. For example Bob might complete the Accounts this year but that makes him no more likely that anyone else to complete them next year, instead that will be whoever has the earliest availability once the information is available.

This is identical to scenario 2a (above) except that a) you do not need the client field and b) you do need the the job position but the field will have no setting in the initial value dropdown.

It is worth noting that you can set up exactly as per scenario 2a and then just leave the regular preparer client fields blank, when a job creates the job position will be empty and can be allocated mid-job.

When adopting this approach it is important to ensure that you use a traffic light workflow action to ensure that the job is allocated at a certain point in the workflow. For example you may decide that all jobs that have reached the stage 'Ready to start' should be blocked until the preparer position becomes occupied. This is a good control because it ensures that one of your team will be seeing the job in their jobs held list. To do this follow the guidance here.

Even if you are following scenario 2a then we would recommend you set up traffic lights, this is just incase a client does not have a user set in the client field.

2c) Staff take jobs from the pool list:

Each of your workflow systems can have a pool activated. This is designed to hold jobs that are at a certain stage(s) but where an allocation needs to be made. Typically (but by no means limited to) the information is ready but no preparer has been set. The job holder is set to the pool and the job is visible on the pool list.

First you should activate the pool (guidance here), once activated your workflows menu will contain a link to the pool for that system.

To get jobs into the pool you need to add a Set job holder workflow action at the point they should enter the pool. This might be on job creation but more often is when the information has been received.

The pool screen will list jobs in the order in which they arrived into the pool, it will list a target date if one is held on the job card and will show and comments that have been added to the job card.

A unique feature of the pool screen (that can not be replicated on say a custom report) is the take button. This button allows users to take a job out of the pool. Of course this could be done by navigating to the job card and changing the job holder etc; however, the take button is more powerful because it triggers a special step in your workflow configuration. You can trigger workflow actions at this point, this can include anything from sending e-mails to setting targets, more guidance is available here. The most popular setting (which is how we have the Glide templates setup) is to set the current user to the preparer position and to make them the current job holder. The latter workflow action means the pool is no longer the job holder so the job is removed from the pool report.

2d) A mixture of the above (regular preparer, allocated mid-job and the pool):

If you have some clients who have a set staff member allocated and some that are allocated during the job then you can simply use the guidance under 2a. In this case if the client has a user allocated to the Regular preparer (or similar) client field then this user will become the Preparer when the job is created. If they do not then the Preparer position will be blank and can be populated mid-job. We would definitely recommend using the traffic light workflow action to insist on the preparer position being completed in this instance.

You can also combine use of a client field such as Regular preparer with the pool system. To do so you need to be allocating to the pool on either the same step (can include job creation) or a latter step as when you would be setting the job holder to your preparer position. On this step firstly add a workflow action to set the job holder to the preparer position then secondly (has to be done in this order) add the workflow action Set job holder (if empty) and choose the pool. This will then set the job holder to the preparer position or, if there is no preparer, then it will set the holder to the pool.

3a) Specific user always does this/that [step in the workflow]:

For example "Bob always sends the final accounts out", meaning Bob completes this step for the entire practice. Firstly you can set Bob to be the current job holder by specifically choosing him in the Set job holder workflow action, this will ensure the job appears in the jobs held widgets on Bob's dashboard, specific guidance here.

You then have the option to set Bob in a job position which may or may not be necessary. Typically these scenarios relate to a specific set of stages or maybe even a specific stage, therefore Bob can have great visibility on the jobs by keeping an eye on those stages in the progress monitor widget. He will be responsible for all of them so should filter the widget to overall, he does not therefore need to set the widget to linked (which will not show these jobs as we have not put him in a job position).

Other benefits of occupying a job position include the ability to send e-mail/SMS updates or alerts to Bob by virtue of his occupying a position. Again this is not really necessary in these simple cases, you can direct messages to specific users or even to the current job holder.

The only reason to put Bob into a position would be if he wants to be able to filter say the progress monitor to the linked view, assumng he is not linked

Long guide: Staff allocation

[To be continued!}