Should I categorise personal tax returns? (UK)

Within the personal tax return workflow system it can be desirable to establish some form of 'sub-category' to reflect the subtly different nature of the returns being completed. This may be to highlight any of the following:

• To split partnership and trust tax returns from individuals.
• To split individuals tax returns further into options such as:
  • Sole trader.
  • Director of a company we act for.
  • Self-assessment.

Glide has several features that will assist you with this, when deciding on how to set up your system, you should consider what your objective is. Generally speaking, it is advisable to only increase the complexity of the setup where there are clear benefits to doing so!

In this article, we shall discuss 4 potential configurations:

1. Having multiple routes on your workflow system.
2. Having multiple sub-systems on your workflow system.
3. Having client data fields such as yes/no and multiple choice.
4. Using tags to send different emails.

1: Having multiple routes on your workflow system:

Every workflow system has a minimum of 1 route (technically, one per sub-system); having multiple routes allows you to differentiate just about everything in a workflow without breaking out into multiple workflow systems. Routes are explained further here.

You should only create multiple routes where there is mutual exclusivity, as a client can only be allocated to one route (again, per sub-system). For example, a tax return client is typically either an individual, a partnership or a trust, so these choices are mutually exclusive. You can reflect this with just 3 route variations.

Conversely, an individual may have self-assessment, rental income, foreign income - or indeed any combination of them. If you try to reflect all combinations in routes, then you will need 7 routes, this is not a good idea!

You might consider having a route for individual, trusts and partnerships if the following benefits offer value to you sufficient to justify the extra data point you need to set when adding a client:

• You want to very easily and visually see the workflow position split between these 3 routes. The key dashboard widget for reviewing job progress, the progress monitor, can be set to show all jobs, a specific route or all jobs with route analysis.
• You want to send different email templates based on the route or no emails on certain routes. This is entirely possible without setting up multiple routes (via differentiating the workflow steps/stages or via tagging) but is made much easier by having the routes. This is especially true for an initial information request which may generate or send automatically soon after the job is created, i.e. before a user interacts with the job. All jobs on a certain route will create onto the same stage meaning you would need to use tags to differentiate the email templates at this point. I.e. emails generated before the jobs have a chance to progress.
• You would like to vary the stages, steps, actions. For example, a partnership return might not have information request stages because the expectation is that the information will be collected from the individual partners returns.

A further benefit of having routes is that your can output or filter by the route in the query editors; however, this can just as easily be achieved via either a multiple choice field or a tag, therefore, I would not set up multiple routes solely for this reason.

Conclusion: If you act for partnerships and trusts, and especially if you are looking to automate lots of personal tax emails, then it seems a no-brainer to follow this approach. You could go further and have routes for different types of individual e.g. 'Director of company we act for' and 'Sole trader' etc.

2: Having multiple sub-systems on your workflow system:

Every workflow system has a minimum of 1 sub-system. You can decide to create additional sub-systems, each of those can then have multiple route variations, if required.

Having 2 sub-systems (for example) is pretty much identical to having 2 jobs except that they co-exist on the same job. When looking at that job card you will see:

• 2 current job stages
• 2 sets of blue progress buttons.
• 2 current job holders.
• 2 lists of stages.
• etc.....

The close relationship between sub-jobs provides some interesting functionality. Sub-systems are explained in more detail here.

Having multiple sub-systems is useful where an overall assignments consists of multiple distinct parts which are highly related but independent of one another. That independence might mean that different people are working on the different parts at the same time. It might mean that you can't predict which parts will progress first. The latter makes it impossible to map everything into a single workflow flow chart.

Sub-systems must share a job date and frequency. E.g. you can't combine quarterly bookkeeping with annual personal tax returns. When the job creates, all active sub-systems will create a sub-job.

The key distinction between sub-systems and routes is that sub-systems can co-exist on a job. If you have 4 sub-systems; A, B, C and D, then a client can be active on any combination of them. You can then have one or multiple different routes for each of A, B, C and D.

Looking across the Glide templates there are 2 great examples of multiple sub-systems being used.

Firstly, on our 'Accounts & CT v2' template, we have a sub-system for Accounts and a sub-system for CT. This works well for customers that either consider the CT to be a separate workflow, or those where the CT will practically be completed out of sync or by a different team member.

It separates them whilst retaining a close link, for example, the Accounts progression might auto-progress the CT or the lack of sign-off on the CT might block the Accounts. Both of these examples could not be achieved (well, not too easily!) were the jobs to be on 2 separate workflow systems.

Secondly, on our 'New client onboarding' flow, we split the job into 4 sub-system:

• Internal processes.
• AML.
• Professional clearance.
• Direct debit.

The independence here is obvious, you will find it hard to control which of the final 3 progresses first and thus you simply can not map this onto a single workflow diagram.

So, where have we seen this work well in personal tax?

If you wish to automate the sending of payment and payment on account reminders, then it works really well to have a sub-system dedicated to tracking this. It can also be useful to split out the refund process into a 3rd sub-system. Both of these examples allow you to automatically progress the payment/refund sub-systems to an appropriate stage (as defined automatically by the choices made on the main tax return flow) whilst continuing with the finalisation of the tax return (i.e. having 2 or 3 current stages is essential here).

We shall link soon to a separate article explaining how to do this.

There may be some benefit to splitting out optional components of a tax return, such as rental income, into a separate sub-system. This is because the existence of rental income co-exists with any of our 3 individual tax return options noted above (sole trade, director, pure SA) - it is not a mutually exclusive choice.

In theory, this can be achieved via a very simple yes/no field (see option 3 below); however, having a dedicated sub-system would effectively provide the yes/no and also a workflow structure to ensure the completion of this section of the return. This setup would usually not influence external emails though because your client probably only wants 1 info request email, for example. Therefore, it would be illogical to have an email sent by the main tax return sub-system and also the rental sub-system. You might accommodate the extra bullet points for the rental info required by having a client specific list or table merged into your email templates, this can be achieved via a custom client field of the type formatted text, explained here.

3: Having client data fields such as yes/no and multiple choice:

If you do not need to vary your workflow stages/steps and you are happy with how your emails are working, then you might consider achieving data analysis by a client data fields.

Data such as whether the client has rental can be held in a boolean (yes/no) field.

Choices such as those in the routes section above (director, sole trader, pure self-assessment etc) can be set up within a multiple choice field.

This is going to be the easiest option to setup but of course carries no additional benefits.

4: Using tags to send different emails:

We discussed above how having multiple routes is a nice way to differentiate emails. Email/SMS automations, via either alerts or actions, are applied to a route and so they would only send to clients on that route. This means that, whilst you may still target a tag (though this is generally not essential on personal tax), the tag does not play a role in selecting the correct email template. All of your emails could simply target the same tag, such as 'Main contact' or 'Tax return'.

If you decided that you only wanted 1 route, then you can still send different email templates to the different types of customers (e.g. sole trader, director etc). You can achieve the same differentiation with tags. All email/SMS automations can be targeted towards a tag (discussed here in option 2). If you set up the following 3 tags:

• Sole trader client.
• Director of company.
• Pure tax return.

Then for each action or alert, you would simply have 3 automations, one targeting each tag. So long as you only apply one tag to each client, then they will only receive one email message.

Within this system, if you fear you or your team might accidentally apply 2 tags to a client (you can have reports checking for instances of this), then you can build in extra resilience once the job has started. For example, where a message is triggered by an action (i.e. typically a user clicking a blue button) then you can simply have > 1 button. Have a button dedicated to each tag which sends only one email.

Similarly, with alerts, you could progress the job to a dedicated stage such as 'Awaiting info - sole trader' and have the alert filtered to that stage only. This way you would only need one alert per stage.

Conclusion: With the additional benefits of having the visibility 'by route' and the ability to vary just about everything in the different versions of the workflow - it seems more logical to go with the routes option than tags. Then you don't need to apply a tag but you may choose to have just one, this provides an easy opt out mechanism and also allows for the circumstance where a client wants their personal tax emails directed to someone else.

Please do contact the Glide Team via the blue button if you would like to discuss these options further.