How to allocate all payroll (etc) jobs to one person.

There are often cases within a team where one person takes full responsibility for a particular area of work, a common example is payroll. On Glide you wish for all jobs to be automatically allocated to this person.

There are a couple of different configurations within Glide that will achieve this, which you choose will depend on whether you see the situation changing in the future, specifically whether you expect the level of work to grow resulting in a second/third person taking responsibility.

Example one below is suitable where do you not see the situation changing and option 2 allows for more scaling of the business without the need to reconfigure Glide. Changing the settings is not very time consuming so do not worry too much about which you choose.

Option 1 -> Jobs passed to specific person:

You will definitely want this person to be the job holder and in this case there is no reason not to set them as the job holder from the second the job is created, therefore we need a workflow action to make them the job holder on the job creation step. Follow the steps below to set this and do this for any routes you have.

1. Note you need to be a superuser to configure workflows.
2. Click on the Config menu.
3. Click on Edit workflow systems.
4. Drill into the appropriate workflow system by clicking on the pencil icon to the right of the name.
5. Click on the workflow routes tab and follow steps 6 and 7 for each workflow route effected.
6. Scroll down to the appropriate route and further to the workflow steps. The very first step is the special step that triggers on job creation. If there is not already a Set job sub-system holder workflow action click Create New Action and choose Set job sub-system holder (the 1st in the list). If one already exists click on the pencil icon to edit the action.
7. When editing the workflow action the lower dropdown box will offer you, amongst other options, every user currently on the system. Choose the user that will be doing the work. Of course you can pass the job to others for certain stages as required, for example if someone else is reviewing the work. Click Save.

This will ensure that the user is holding the job so the jobs will appear in his/her jobs held widgets and reports which are generally designed to help users see what work they need to do and to help others appreciate how busy they are.

In addition you may wish to link the user to the job using a job position. It is worth explaining when this would be useful and when it would not be useful.

If the user is planning to use only widgets that are specific to this workflow system for example the progress monitor and (if applicable) the deadline monitor then they do not actually need to be linked to the job. They can simply filter these widget to Overall and they will see all of the jobs. If the user is using various widgets that he/she needs to be filtered to Linked (e.g. there are likely to be jobs in other workflow systems that the user is not linked to which would otherwise appear) and if the user wishes these jobs to appear in those widgets along with others then the user needs to be linked to the job.

To link the user you would activate a position such as Preparer and on the same job creation step we would want a workflow action that puts this user in the position. The process to set up this is almost identical to the steps above, the only difference is that you would choose the workflow action called Set job position to a user, then select both the position and the user.

Option 2 -> More scalable setup:

Option 2 essentially mimics the recommended setup where multiple people might work on jobs in a workflow system, the only difference being that the same person occupies the position for all clients. You can read about how to set this up here and specifically thinking about how to have the same person occupy the position for all clients you could use a default user on the client level job field. This will mean that all clients default to this user but can be changed to someone else as and when required. Note that the default value is read on job creation, if you set this after jobs exist you would need to update all jobs which you can do via a bulk update.