FAQs

AXLR8 configure Information Request Types for you. We make sure they have the correct “clock” settings, privacy flags and auto-deletion parameters for your Retention Policy. We have templates ready for most jurisdictions.

Here are three examples from our Demo system. Please also see Request Status which works with Request Types to enable events (e.g. “clarification” or “quotation” or “checking proof of ID” or closure) to stop, pause or reset the “clock” as appropriate.

FOI Request Type

The clock is set to ignore bank holidays. Privacy is not flagged (although, see below for “Sensitive FOI”)

Extended FOI

For those FOI requests that require more time – say 40 days, you can create a variant of the FOI Request Type. The only difference is that it has a 40 day “clock”. If you change from and FOI to an FOI – Extended, the deadline will automatically change. Thus, for example, if you realise, on day 9, that an FOI will be much more work, then you have 11 working days to go. If you simply change the Request Type in the drop down box, then you will automatically see the deadline date change to 31 working days hence. The set up ALR8 apply to this is shown below. Some clients have also asked us for other extensions on Request Types.

SAR Request Type

The clock runs including weekends and bank/public holidays. I.e. it works on Calendar days. It is also “Private“.

Sensitive FOI

This is a Request Type for FOIs that include personal, private content. The clock can still run as an FOI but the “Private” flag is set both internally and externally. The “Public” flag is not set. Some organisations ask AXLR8 to set the DPA flag and treat them fully as if they were SARs. They may be Sensitive FOIs for other reasons.

How configuring a Request Type changes IR lifecycle

How else to these parameters change the way the AXLR8 system manages IRs?

1. Length of time to deadline for response progress tracking
2. Appearance or not on the Public Disclosure Log
3. Colours to distinguish them on reports built with AXLR8 Report Builder
4. Privacy settings for users (most of whom will not see “private” flagged request types.
5. Working days (exclude weekends and public holidays set by your organisation in Bank Holiday Admin) or Calendar days.
6. Whether it is in DPA or FOI or EIR reports and screens
7. How retention automation works
8. …………………..and many more.

It is critical to get the Request Types configured correctly. You can see the implications from the list above. We need to consider every dependency.

If you need any changes to your request types, please contact AXLR8 Support. We will be happy to help. You can read the Request Type Admin area but not make any changes yourself. Your AXLR8 Support consultant will ask you for details and configure and test it across business rules with a programmer.

Information Request Workflow Automation was introduced here as a way to improve productivity for public sector IG Teams. Some Use cases are listed. We show how one of them might be automated and how the User Permissions work to make sure only the correct people design and deploy the robots.

Proof of Identity Workflow Automation

The example below is a abridged schematic of SAR workflow. Obviously, there is much more to it and more detailed workflow charts can be found elsewhere on this site.

Automation steps

Typically, the process building this in to your AXLR8 IRMS starts with your requirements.

1. In Document Template Admin, build the messages for each stage in the medium desired.  Usually these will be emails, SMS Messages or Word documents. For example reminders using Trigaware™ after waiting for a PoID for a SAR.  The messaging can be simple or intelligent with personalisation and very specific conditional contents. (see smart messaging).
2. We set up a “custom event definition” (i.e. the point in your workflow at which you need the document to go to the client).
3. Define the Status Life Cycle: the next section describes how to define a time limit for a status and any status change that follows completion of that life cycle. The life (cycle) of a status is the time it runs for or period before it closes itself and kicks off the new status.

Stage 1 Messaging to match your status change requirement

These examples match the work flow above.

• Inform the applicant that the IG team need this from the applicant when the IR is set to “Clarification Requested”
• Then alert them that 20 days has passed and there are 20 days remaining before they will have to resubmit their request. This would happen when the Clarification Second Request auto launched itself.
• The IR will close when the 40 days end and there has been no Clarification (or PoID). A third Trigger email can be programmed to go out. It would inform the applicant that their IR is now closed. They will have to resubmit it if they still need the information.

Stage 2: Create Automated Information Request

The best way to accomplish your objectives for Information Request automations is to create new IR Statuses. The reason for this is that all existing IRs that are running with that status will suddenly automate. If that is OK with you, go for it. We will describe how you do that below but you should consider the safer route of creating and applying a new one.

Please refer to the screenshots below which show the update of an IR Status and the creation of a new one.
The existing IR Status called “SAR ID Requested” for this client could be upgraded by:

• adding the tick for Time limited Status
• adding a duration of 20 days
• selecting a carry on status (in this case it will “Final SAR Request”)
• ticking the box for Special User Access. (see “User Permissions” below)

So after 20 days from the initial request, the IR is automatically sent to the next status of a final 20 days where they are on notice that the IR will be closed after that period. This is a total of 40 days. Very reasonable if you automate some reminders for the applicant as well.

In the above example, we updated and existing IR Status for our first 20 day SAR Request for PoID. Below we have created a new Information Request Status, also 20 days in duration and the last 20 day period they have in which to prove they are who they say they are before work starts finding their requested information. In the green box, to confirm the process above, we did the same ticks and duration. The difference is that the end of the 20 days automatically changes the status to Cancelled by Requester. Again, your organisation may have different vocabulary. You might call that “Failed to supply PoID” or some other label. In any case, it would close the IR because this final status would be a “finished” status.

So, we now have a “chain” of three actions that will hand over like a relay race with no human intervention necessary until PoID is received and agreed as valid, one day. Then the automated process is stopped and work begins with that request.

NB in the above example, you will see that this IR Status is disabled (tick box at the top). That is because We have not yet applied user permissions (or tested it).

Note. It is best not to apply the time limited status settings to existing IR statuses unless you are confident you know the outcome.  The next time it runs, it would run on all the existing IR records that have that existing status. Do you want that?  If you do make a status time limited, it would be best to search to see how many IR’s have that status, and understand that if they were given it more than the duration number of “valid” days ago, that “it will” change the status next time it runs.

Stage 3. Review User Permissions

Not all users should have the authority or expertise to apply a timed status. They may launch a wrong workflow automation. For example, without knowing the next steps, they could create an infinite loop. Users need to have the new user permission to apply one of these time limited statuses when they are first created. Later, when ta few runs through have proven the automations, you can remove the restriction from the IR status. This is done by removing the “Special User Access” shown in the screenshots in the previous stage. Below is how we can set up a knowledgeable pilot user to be able to use the new timed IR Statuses.

There is a new User Permission. It is called “Can apply Special User Access Statuses”, on user admin. Here is an example from a real client showing where it is on the User Admin screen.

If a User tries to apply a Time Limited IR Status to an Information Request, they may not be able to do so. If they do not have permission, they will get the following message.

For someone with this permission, the above alert message (example from City of Edinburgh) will not appear. That User can save their chosen status.

Systems Admin Permissions

As described above, your Super Users may decide which Users may apply these IR Statuses with timings built in. I.e. the “special User Access” IR statuses.

We have disabled update rights for clients but you have complete visibility of information Request Statuses. You can request an AXLR8 consultant to make the change.  Thus in your office, similar to the Dropdowns admin for Request Type, the Dropdowns Admin for Information Request Status only has a Save function when one of our consultants is using it. 
It is not available from client offices. AXLR8 have retained some of the administrative privileges for our support specialists for Request Status Admin.

The “Save” function in Information Request Status “Dropdowns Admin” was always available for Super Users at our clients. However, the ability to save changes in Request Type was reserved for AXLR8 consultants. The reason was the cost to us of fixing mistakes. With the power of this new Workflow automation we need to work with a few clients to take responsibility and shoulder the expense of any errors before handing back the ability to save changes. We also assume most client Super Users would wish to work over a Teams meeting screenshare with an AXLR8 support consultant when building these IR Automations. The reason is that mistakes can be costly to fix.

Audit Log

In the audit log view we can see the Cancelled status is a “Close” status, the save object has also set the “Date Closed” date (same as if you set the IR to cancelled in the IR details screen).

Why must we update Bank Holiday dates? Some information requests have a response deadline in Calendar Days, e.g. SARs. Others like FOI and EIR must be completed in Working days. These “Request Types” are configured in Request Type Admin.

The AXLR8 system must exclude weekends and public holidays for those Request Types. Request Types change from jurisdiction to jurisdiction and in some countries local areas may differ. So, AXLR8 have a simple solution. We provide a Bank Holiday Admin area where you can manage your organisation’s public holiday dates.

Bank Holiday Admin

The Bank Holiday Admin function is to be found in the Super User menu. It is down at the bottom. The reason is that it is not used very often. You can add a few years in ahead if you wish. Don’t forget a diary date to review them.

You can add (or remove) dates for public holidays. This is shown below.

These days are excluded from the day-count up to the response deadline.

Responsibility for updating Bank Holidays

You, the client, are responsible for keeping your Bank Holidays updated. We enter the pubic holidays for a year with you as part of the Super User Systems Admin training. This is done when we first implement your system.

Occasionally, we find a client who has forgotten to update them after that.

We sometimes ask clients if they would like one of our interns to help. It is a good “work experience” job. This might be whilst working on their system on another support job. In that case, we inform the client. Please do not rely upon it. Set a date in your diary. Once a year should do it. There are too many clients and local variations for AXLR8 to manage it centrally.

There are several approaches you can take. Here are the three most popular.

Make it a Sensitive FOI

This is an FOI request that requires personal data in the answer which you feel should be protected as if it were a SAR.

A question about several streets might be FOI but a question a bout a specific house identifies a resident and may thus include PII.

Let’s say there are 5 parts to a question which is about compensation of nurses. Part 3 asks you about the applicant’s specific compensation but the rest are about general rules and amounts over the last couple of years.

In both examples one may chjoose to use a “Sensitive FOI”. That request type should be configured as “Private” and hence it will not

1. appear in the PDL (Public Disclosure Log)
2. be visible to staff with out access to Private Request Types

Make it a SAR

It may be that the request is so peculiar to a person that it is really a SAR. This happens occasionally and is a natural solution which immediately covers you for any possibility that the data will be published outside your organisation. It will also not be seen by those without “Private” Request Type access.

Make two IRs: a SAR and and EIR

There may be a number of questions in the IR and you can create two IRs. Let us take the above example with 5 parts. Part 3 could be a SAR and parts 1,2,4&5 could be sent out in a second IR which was classified as an FOI request.

Which to choose?

Obviously, the first is the simplest. The advantages of a “sensitive” FOI (FOISA, EIR, etc.) are that they are excluded from the Public Disclosure Log and are not seen by any staff whose access excludes Private request types.

The automated emails will have been set up so that they do not expose PII in the wrong places. Policies and workflow procedures would need to be in place so that the information management team know to make the subject line “Bill Smith’s Compensation” (in the above example). Rather they might make the correspondence subject “Potholes Compensation”.

The only other thing to consider is triage speed. Once you have set an IR as FOI, some automated triggers may have been launched. That needs to be taken into account before changing the request to a Sensitive FOI or SAR after a week of activity. Occasionally, however, it is not obvious for an officer at first. Senior staff are not present and a mistake is made.

What if I change IR Types during a response period?

There is a related article about what happens to the Countdown and Due Date when you change and IR Type from FOI to SAR.

What are Private Request Types?

Generally, these Requests would be SARs, Sensitive FOIs and some that are specific to different jurisdictions. Examples include: CAFCAS in UK and Procurator Fiscal in Scotland.

Please see the FAQ article about configuring Request Types. It explains how their behaviour differs in the AXLR8 system.

Sometimes the original Information Request Type must change. What happens to the Due Date?
The most obvious example is when you log an FOI request thinking it is simple and it turns out to be more complex. It might be that clarification by the applicant expands the scope or the department providing some or all of the expertise explains an unforseen depth and raises more questions than answers.

Example 1: FOI changes to FOI Extended

An FOI request allows you 20 working days to respond. Bank Holidays in your jurisdiction and weekends are excluded. If a request is complex or more time is required, you may be able to extend that response time to 40 working days. In some jurisdictions there may also be 60 day FOI periods.
You can start with an FOI request and realise at some point that it will not be as simple to respond as had originally been thought. Therefore, you can change it to an “FOI Extended” with 40 days to respond. The AXLR8 system will then take the days that have already run and recalculate the new due date and hence the days outstanding wil have 20 days added on.

Let us take a simple example. FOI Request 1234 comes in and is set as an FOI 20 request type. The code indicates that it is and FOI request and has 20 working dats to run. It comes in on 11/04/2025, the day I am writing this FAQ. The due date will become 14/05/2025. Please note I took this from Demoshire2 which is presently set to English Bank Holidays in 2025 ( April 18 & 21, May 5 & 26 and Aug 25th). Assume for now that no restart for Clarification was required.

Let’s say it runs for 5 working days. Now, there are 15 working days left. I decide it is a 40 day FOI request instead. Then the clock will keep the days already used but the due date will be calculated as if it had been a 40 day request in the first place. So, it will change the due date to 12/06/2025. and the countdown will change from 15 days left to 35 days left. You can see why the public holidays were mentioned above!

Example 2: FOI changes to DPA Access then to DPA Access Extended

This was a real query from a client.

“We also have a query about request types changing throughout the request life, and how this changes the due date on requests (e.g. if a request is first thought to be FOISA , then changed to DPA – Access request and then changed to DPA – Access complex).“

We can use this as an example and apply the principles above. Same public holidays for simplicity even though this actually came from a different jurisdiction – Scotland whose bank holidays are different as yours may be. We have applied the rule that a response last day for a DPA/SAR may not fall on a weekend or bank holiday.

NB Please assume that any clarification or proof of ID has taken place beforehand. If it had not, the system would deal with those legitimate delays. It recalculates the Due Date as events take place.

AXLR8 are enhancing the system to work with calendar months. Choosing 28 days is accepted by most jurisdictions ( e.g. OIC). However, our feedback is that clients would prefer precise calendar months. This means that an IG team can complete a request in a 31 day month in 29 or 30 days. KPI reports will not show it as late. This new development is expected soon.

Example 3: May 25th 2018 – introduction of GDPR

The rules all changed for GDPR. AXLR8 just made the SAR requests starting on that Friday morning of the 25th run for a month. This is still the rule. Previously you were allowed 40 calendar days.

Every DPA request logged before midnight on 24th ran through to the end of its 40 day pre-GDPR processing time. So, AXLR8 made this enormous transition without any adverse results or extra charges.

Additional extended periods for more demanding SARS could also be chosen after that time.

Audit Trail

NB the changes made will be in the audit trail and so there is a visible “journey”. You can track how and when, the Coundown and Due Date has changed. It also shows which user made those changes.

KPIs

The Reports will accurately present the statistics. For example, it will show those responses which were late or on time and by how many days.

Questions?

You may have other examples and wish to play them through our system to check them.

Please do not hestiate to ask.

Short answer, anything you want during any timescale you can afford.

However, this is a standard AXLR8 demo of 48 minutes plus questions.

Items such as migration from legacy systems and security and other areas of compliance required in the public sector will be dealt with in depth if required at a later stage.

Other tools

If of interest, we can always look at other IG tools later Data Breach, DPIA, Information Asset Register, Data Sharing Policy Register, etc.  Also, Complaints Processing and other workflows.

AXLR8 configure Information Request Types for you. We make sure they have the correct “clock” settings, privacy flags and auto-deletion parameters for your Retention Policy. We have templates ready for most jurisdictions.

Here are three examples from our Demo system. Please also see Request Status which works with Request Types to enable events (e.g. “clarification” or “quotation” or “checking proof of ID” or closure) to stop, pause or reset the “clock” as appropriate.

FOI Request Type

The clock is set to ignore bank holidays. Privacy is not flagged (although, see below for “Sensitive FOI”)

Extended FOI

For those FOI requests that require more time – say 40 days, you can create a variant of the FOI Request Type. The only difference is that it has a 40 day “clock”. If you change from and FOI to an FOI – Extended, the deadline will automatically change. Thus, for example, if you realise, on day 9, that an FOI will be much more work, then you have 11 working days to go. If you simply change the Request Type in the drop down box, then you will automatically see the deadline date change to 31 working days hence. The set up ALR8 apply to this is shown below. Some clients have also asked us for other extensions on Request Types.

SAR Request Type

The clock runs including weekends and bank/public holidays. I.e. it works on Calendar days. It is also “Private“.

Sensitive FOI

This is a Request Type for FOIs that include personal, private content. The clock can still run as an FOI but the “Private” flag is set both internally and externally. The “Public” flag is not set. Some organisations ask AXLR8 to set the DPA flag and treat them fully as if they were SARs. They may be Sensitive FOIs for other reasons.

How configuring a Request Type changes IR lifecycle

How else to these parameters change the way the AXLR8 system manages IRs?

1. Length of time to deadline for response progress tracking
2. Appearance or not on the Public Disclosure Log
3. Colours to distinguish them on reports built with AXLR8 Report Builder
4. Privacy settings for users (most of whom will not see “private” flagged request types.
5. Working days (exclude weekends and public holidays set by your organisation in Bank Holiday Admin) or Calendar days.
6. Whether it is in DPA or FOI or EIR reports and screens
7. How retention automation works
8. …………………..and many more.

It is critical to get the Request Types configured correctly. You can see the implications from the list above. We need to consider every dependency.

If you need any changes to your request types, please contact AXLR8 Support. We will be happy to help. You can read the Request Type Admin area but not make any changes yourself. Your AXLR8 Support consultant will ask you for details and configure and test it across business rules with a programmer.

There are several approaches you can take. Here are the three most popular.

Make it a Sensitive FOI

This is an FOI request that requires personal data in the answer which you feel should be protected as if it were a SAR.

A question about several streets might be FOI but a question a bout a specific house identifies a resident and may thus include PII.

Let’s say there are 5 parts to a question which is about compensation of nurses. Part 3 asks you about the applicant’s specific compensation but the rest are about general rules and amounts over the last couple of years.

In both examples one may chjoose to use a “Sensitive FOI”. That request type should be configured as “Private” and hence it will not

1. appear in the PDL (Public Disclosure Log)
2. be visible to staff with out access to Private Request Types

Make it a SAR

It may be that the request is so peculiar to a person that it is really a SAR. This happens occasionally and is a natural solution which immediately covers you for any possibility that the data will be published outside your organisation. It will also not be seen by those without “Private” Request Type access.

Make two IRs: a SAR and and EIR

There may be a number of questions in the IR and you can create two IRs. Let us take the above example with 5 parts. Part 3 could be a SAR and parts 1,2,4&5 could be sent out in a second IR which was classified as an FOI request.

Which to choose?

Obviously, the first is the simplest. The advantages of a “sensitive” FOI (FOISA, EIR, etc.) are that they are excluded from the Public Disclosure Log and are not seen by any staff whose access excludes Private request types.

The automated emails will have been set up so that they do not expose PII in the wrong places. Policies and workflow procedures would need to be in place so that the information management team know to make the subject line “Bill Smith’s Compensation” (in the above example). Rather they might make the correspondence subject “Potholes Compensation”.

The only other thing to consider is triage speed. Once you have set an IR as FOI, some automated triggers may have been launched. That needs to be taken into account before changing the request to a Sensitive FOI or SAR after a week of activity. Occasionally, however, it is not obvious for an officer at first. Senior staff are not present and a mistake is made.

What if I change IR Types during a response period?

There is a related article about what happens to the Countdown and Due Date when you change and IR Type from FOI to SAR.

What are Private Request Types?

Generally, these Requests would be SARs, Sensitive FOIs and some that are specific to different jurisdictions. Examples include: CAFCAS in UK and Procurator Fiscal in Scotland.

Please see the FAQ article about configuring Request Types. It explains how their behaviour differs in the AXLR8 system.

Generally these would be SARs, Sensitive FOIs and some that are specific to different jurisdictions. Examples include: CAFCAS in UK and Procurator Fiscal in Scotland.

The Request Types in the AXLR8 system are completely customisable for any jurisdiction (or just because your organisation needs to). This means setting it up with the “Private” parameter set to “Yes”. It may also be that there are Request Types that are not private but may not be shown on the Public Disclosure Log. That can be set separately as you can see in the orange box below.

How does the AXLR8 system treat Private Request Types?

1. Only those with Private IR access may see them. This is different to the Application Blind parameter in User Admin which prevents a user seeing any applicant details, regardless of the type of request.
2. The automated emails can be set up differently. For example, the Subject line of email correspondence and file names of documents may say the Request Type and the unique reference number. For example the subject line might say “SAR- ACCESS demoshireIR:12345” but not the name of the applicant for who you are collecting the information. Compare this with the subject line for an FOI request which would say “Potholes vehicle damage compensation FY2023-4 DemoshireIR:12346“.
3. The Request will not show on the PDL (Public Disclosure Log) for your organisation.

Response Times

The response times are unaffected by the “Private” flag shown above. How these timings work as well as how they change with clarifications and proof of identity and other events is described elsewhere.

The time for completion is set elsewhere. A Sensitive FOI (assuming not extended) still runs to a deadline of 20 working days. A SAR still has a month regardless of bank holidays and weekends.

Short answer, anything you want during any timescale you can afford.

However, this is a standard AXLR8 demo of 48 minutes plus questions.

Items such as migration from legacy systems and security and other areas of compliance required in the public sector will be dealt with in depth if required at a later stage.

Other tools

If of interest, we can always look at other IG tools later Data Breach, DPIA, Information Asset Register, Data Sharing Policy Register, etc.  Also, Complaints Processing and other workflows.

AXLR8 configure Information Request Types for you. We make sure they have the correct “clock” settings, privacy flags and auto-deletion parameters for your Retention Policy. We have templates ready for most jurisdictions.

Here are three examples from our Demo system. Please also see Request Status which works with Request Types to enable events (e.g. “clarification” or “quotation” or “checking proof of ID” or closure) to stop, pause or reset the “clock” as appropriate.

FOI Request Type

The clock is set to ignore bank holidays. Privacy is not flagged (although, see below for “Sensitive FOI”)

Extended FOI

For those FOI requests that require more time – say 40 days, you can create a variant of the FOI Request Type. The only difference is that it has a 40 day “clock”. If you change from and FOI to an FOI – Extended, the deadline will automatically change. Thus, for example, if you realise, on day 9, that an FOI will be much more work, then you have 11 working days to go. If you simply change the Request Type in the drop down box, then you will automatically see the deadline date change to 31 working days hence. The set up ALR8 apply to this is shown below. Some clients have also asked us for other extensions on Request Types.

SAR Request Type

The clock runs including weekends and bank/public holidays. I.e. it works on Calendar days. It is also “Private“.

Sensitive FOI

This is a Request Type for FOIs that include personal, private content. The clock can still run as an FOI but the “Private” flag is set both internally and externally. The “Public” flag is not set. Some organisations ask AXLR8 to set the DPA flag and treat them fully as if they were SARs. They may be Sensitive FOIs for other reasons.

How configuring a Request Type changes IR lifecycle

How else to these parameters change the way the AXLR8 system manages IRs?

1. Length of time to deadline for response progress tracking
2. Appearance or not on the Public Disclosure Log
3. Colours to distinguish them on reports built with AXLR8 Report Builder
4. Privacy settings for users (most of whom will not see “private” flagged request types.
5. Working days (exclude weekends and public holidays set by your organisation in Bank Holiday Admin) or Calendar days.
6. Whether it is in DPA or FOI or EIR reports and screens
7. How retention automation works
8. …………………..and many more.

It is critical to get the Request Types configured correctly. You can see the implications from the list above. We need to consider every dependency.

If you need any changes to your request types, please contact AXLR8 Support. We will be happy to help. You can read the Request Type Admin area but not make any changes yourself. Your AXLR8 Support consultant will ask you for details and configure and test it across business rules with a programmer.

Information Request Workflow Automation was introduced here as a way to improve productivity for public sector IG Teams. Some Use cases are listed. We show how one of them might be automated and how the User Permissions work to make sure only the correct people design and deploy the robots.

Proof of Identity Workflow Automation

The example below is a abridged schematic of SAR workflow. Obviously, there is much more to it and more detailed workflow charts can be found elsewhere on this site.

Automation steps

Typically, the process building this in to your AXLR8 IRMS starts with your requirements.

1. In Document Template Admin, build the messages for each stage in the medium desired.  Usually these will be emails, SMS Messages or Word documents. For example reminders using Trigaware™ after waiting for a PoID for a SAR.  The messaging can be simple or intelligent with personalisation and very specific conditional contents. (see smart messaging).
2. We set up a “custom event definition” (i.e. the point in your workflow at which you need the document to go to the client).
3. Define the Status Life Cycle: the next section describes how to define a time limit for a status and any status change that follows completion of that life cycle. The life (cycle) of a status is the time it runs for or period before it closes itself and kicks off the new status.

Stage 1 Messaging to match your status change requirement

These examples match the work flow above.

• Inform the applicant that the IG team need this from the applicant when the IR is set to “Clarification Requested”
• Then alert them that 20 days has passed and there are 20 days remaining before they will have to resubmit their request. This would happen when the Clarification Second Request auto launched itself.
• The IR will close when the 40 days end and there has been no Clarification (or PoID). A third Trigger email can be programmed to go out. It would inform the applicant that their IR is now closed. They will have to resubmit it if they still need the information.

Stage 2: Create Automated Information Request

The best way to accomplish your objectives for Information Request automations is to create new IR Statuses. The reason for this is that all existing IRs that are running with that status will suddenly automate. If that is OK with you, go for it. We will describe how you do that below but you should consider the safer route of creating and applying a new one.

Please refer to the screenshots below which show the update of an IR Status and the creation of a new one.
The existing IR Status called “SAR ID Requested” for this client could be upgraded by:

• adding the tick for Time limited Status
• adding a duration of 20 days
• selecting a carry on status (in this case it will “Final SAR Request”)
• ticking the box for Special User Access. (see “User Permissions” below)

So after 20 days from the initial request, the IR is automatically sent to the next status of a final 20 days where they are on notice that the IR will be closed after that period. This is a total of 40 days. Very reasonable if you automate some reminders for the applicant as well.

In the above example, we updated and existing IR Status for our first 20 day SAR Request for PoID. Below we have created a new Information Request Status, also 20 days in duration and the last 20 day period they have in which to prove they are who they say they are before work starts finding their requested information. In the green box, to confirm the process above, we did the same ticks and duration. The difference is that the end of the 20 days automatically changes the status to Cancelled by Requester. Again, your organisation may have different vocabulary. You might call that “Failed to supply PoID” or some other label. In any case, it would close the IR because this final status would be a “finished” status.

So, we now have a “chain” of three actions that will hand over like a relay race with no human intervention necessary until PoID is received and agreed as valid, one day. Then the automated process is stopped and work begins with that request.

NB in the above example, you will see that this IR Status is disabled (tick box at the top). That is because We have not yet applied user permissions (or tested it).

Note. It is best not to apply the time limited status settings to existing IR statuses unless you are confident you know the outcome.  The next time it runs, it would run on all the existing IR records that have that existing status. Do you want that?  If you do make a status time limited, it would be best to search to see how many IR’s have that status, and understand that if they were given it more than the duration number of “valid” days ago, that “it will” change the status next time it runs.

Stage 3. Review User Permissions

Not all users should have the authority or expertise to apply a timed status. They may launch a wrong workflow automation. For example, without knowing the next steps, they could create an infinite loop. Users need to have the new user permission to apply one of these time limited statuses when they are first created. Later, when ta few runs through have proven the automations, you can remove the restriction from the IR status. This is done by removing the “Special User Access” shown in the screenshots in the previous stage. Below is how we can set up a knowledgeable pilot user to be able to use the new timed IR Statuses.

There is a new User Permission. It is called “Can apply Special User Access Statuses”, on user admin. Here is an example from a real client showing where it is on the User Admin screen.

If a User tries to apply a Time Limited IR Status to an Information Request, they may not be able to do so. If they do not have permission, they will get the following message.

For someone with this permission, the above alert message (example from City of Edinburgh) will not appear. That User can save their chosen status.

Systems Admin Permissions

As described above, your Super Users may decide which Users may apply these IR Statuses with timings built in. I.e. the “special User Access” IR statuses.

We have disabled update rights for clients but you have complete visibility of information Request Statuses. You can request an AXLR8 consultant to make the change.  Thus in your office, similar to the Dropdowns admin for Request Type, the Dropdowns Admin for Information Request Status only has a Save function when one of our consultants is using it. 
It is not available from client offices. AXLR8 have retained some of the administrative privileges for our support specialists for Request Status Admin.

The “Save” function in Information Request Status “Dropdowns Admin” was always available for Super Users at our clients. However, the ability to save changes in Request Type was reserved for AXLR8 consultants. The reason was the cost to us of fixing mistakes. With the power of this new Workflow automation we need to work with a few clients to take responsibility and shoulder the expense of any errors before handing back the ability to save changes. We also assume most client Super Users would wish to work over a Teams meeting screenshare with an AXLR8 support consultant when building these IR Automations. The reason is that mistakes can be costly to fix.

Audit Log

In the audit log view we can see the Cancelled status is a “Close” status, the save object has also set the “Date Closed” date (same as if you set the IR to cancelled in the IR details screen).

There are several approaches you can take. Here are the three most popular.

Make it a Sensitive FOI

This is an FOI request that requires personal data in the answer which you feel should be protected as if it were a SAR.

A question about several streets might be FOI but a question a bout a specific house identifies a resident and may thus include PII.

Let’s say there are 5 parts to a question which is about compensation of nurses. Part 3 asks you about the applicant’s specific compensation but the rest are about general rules and amounts over the last couple of years.

In both examples one may chjoose to use a “Sensitive FOI”. That request type should be configured as “Private” and hence it will not

1. appear in the PDL (Public Disclosure Log)
2. be visible to staff with out access to Private Request Types

Make it a SAR

It may be that the request is so peculiar to a person that it is really a SAR. This happens occasionally and is a natural solution which immediately covers you for any possibility that the data will be published outside your organisation. It will also not be seen by those without “Private” Request Type access.

Make two IRs: a SAR and and EIR

There may be a number of questions in the IR and you can create two IRs. Let us take the above example with 5 parts. Part 3 could be a SAR and parts 1,2,4&5 could be sent out in a second IR which was classified as an FOI request.

Which to choose?

Obviously, the first is the simplest. The advantages of a “sensitive” FOI (FOISA, EIR, etc.) are that they are excluded from the Public Disclosure Log and are not seen by any staff whose access excludes Private request types.

The automated emails will have been set up so that they do not expose PII in the wrong places. Policies and workflow procedures would need to be in place so that the information management team know to make the subject line “Bill Smith’s Compensation” (in the above example). Rather they might make the correspondence subject “Potholes Compensation”.

The only other thing to consider is triage speed. Once you have set an IR as FOI, some automated triggers may have been launched. That needs to be taken into account before changing the request to a Sensitive FOI or SAR after a week of activity. Occasionally, however, it is not obvious for an officer at first. Senior staff are not present and a mistake is made.

What if I change IR Types during a response period?

There is a related article about what happens to the Countdown and Due Date when you change and IR Type from FOI to SAR.

What are Private Request Types?

Generally, these Requests would be SARs, Sensitive FOIs and some that are specific to different jurisdictions. Examples include: CAFCAS in UK and Procurator Fiscal in Scotland.

Please see the FAQ article about configuring Request Types. It explains how their behaviour differs in the AXLR8 system.

Generally these would be SARs, Sensitive FOIs and some that are specific to different jurisdictions. Examples include: CAFCAS in UK and Procurator Fiscal in Scotland.

The Request Types in the AXLR8 system are completely customisable for any jurisdiction (or just because your organisation needs to). This means setting it up with the “Private” parameter set to “Yes”. It may also be that there are Request Types that are not private but may not be shown on the Public Disclosure Log. That can be set separately as you can see in the orange box below.

How does the AXLR8 system treat Private Request Types?

1. Only those with Private IR access may see them. This is different to the Application Blind parameter in User Admin which prevents a user seeing any applicant details, regardless of the type of request.
2. The automated emails can be set up differently. For example, the Subject line of email correspondence and file names of documents may say the Request Type and the unique reference number. For example the subject line might say “SAR- ACCESS demoshireIR:12345” but not the name of the applicant for who you are collecting the information. Compare this with the subject line for an FOI request which would say “Potholes vehicle damage compensation FY2023-4 DemoshireIR:12346“.
3. The Request will not show on the PDL (Public Disclosure Log) for your organisation.

Response Times

The response times are unaffected by the “Private” flag shown above. How these timings work as well as how they change with clarifications and proof of identity and other events is described elsewhere.

The time for completion is set elsewhere. A Sensitive FOI (assuming not extended) still runs to a deadline of 20 working days. A SAR still has a month regardless of bank holidays and weekends.

Sometimes the original Information Request Type must change. What happens to the Due Date?
The most obvious example is when you log an FOI request thinking it is simple and it turns out to be more complex. It might be that clarification by the applicant expands the scope or the department providing some or all of the expertise explains an unforseen depth and raises more questions than answers.

Example 1: FOI changes to FOI Extended

An FOI request allows you 20 working days to respond. Bank Holidays in your jurisdiction and weekends are excluded. If a request is complex or more time is required, you may be able to extend that response time to 40 working days. In some jurisdictions there may also be 60 day FOI periods.
You can start with an FOI request and realise at some point that it will not be as simple to respond as had originally been thought. Therefore, you can change it to an “FOI Extended” with 40 days to respond. The AXLR8 system will then take the days that have already run and recalculate the new due date and hence the days outstanding wil have 20 days added on.

Let us take a simple example. FOI Request 1234 comes in and is set as an FOI 20 request type. The code indicates that it is and FOI request and has 20 working dats to run. It comes in on 11/04/2025, the day I am writing this FAQ. The due date will become 14/05/2025. Please note I took this from Demoshire2 which is presently set to English Bank Holidays in 2025 ( April 18 & 21, May 5 & 26 and Aug 25th). Assume for now that no restart for Clarification was required.

Let’s say it runs for 5 working days. Now, there are 15 working days left. I decide it is a 40 day FOI request instead. Then the clock will keep the days already used but the due date will be calculated as if it had been a 40 day request in the first place. So, it will change the due date to 12/06/2025. and the countdown will change from 15 days left to 35 days left. You can see why the public holidays were mentioned above!

Example 2: FOI changes to DPA Access then to DPA Access Extended

This was a real query from a client.

“We also have a query about request types changing throughout the request life, and how this changes the due date on requests (e.g. if a request is first thought to be FOISA , then changed to DPA – Access request and then changed to DPA – Access complex).“

We can use this as an example and apply the principles above. Same public holidays for simplicity even though this actually came from a different jurisdiction – Scotland whose bank holidays are different as yours may be. We have applied the rule that a response last day for a DPA/SAR may not fall on a weekend or bank holiday.

NB Please assume that any clarification or proof of ID has taken place beforehand. If it had not, the system would deal with those legitimate delays. It recalculates the Due Date as events take place.

AXLR8 are enhancing the system to work with calendar months. Choosing 28 days is accepted by most jurisdictions ( e.g. OIC). However, our feedback is that clients would prefer precise calendar months. This means that an IG team can complete a request in a 31 day month in 29 or 30 days. KPI reports will not show it as late. This new development is expected soon.

Example 3: May 25th 2018 – introduction of GDPR

The rules all changed for GDPR. AXLR8 just made the SAR requests starting on that Friday morning of the 25th run for a month. This is still the rule. Previously you were allowed 40 calendar days.

Every DPA request logged before midnight on 24th ran through to the end of its 40 day pre-GDPR processing time. So, AXLR8 made this enormous transition without any adverse results or extra charges.

Additional extended periods for more demanding SARS could also be chosen after that time.

Audit Trail

NB the changes made will be in the audit trail and so there is a visible “journey”. You can track how and when, the Coundown and Due Date has changed. It also shows which user made those changes.

KPIs

The Reports will accurately present the statistics. For example, it will show those responses which were late or on time and by how many days.

Questions?

You may have other examples and wish to play them through our system to check them.

Please do not hestiate to ask.

Short answer, anything you want during any timescale you can afford.

However, this is a standard AXLR8 demo of 48 minutes plus questions.

Items such as migration from legacy systems and security and other areas of compliance required in the public sector will be dealt with in depth if required at a later stage.

Other tools

If of interest, we can always look at other IG tools later Data Breach, DPIA, Information Asset Register, Data Sharing Policy Register, etc.  Also, Complaints Processing and other workflows.

AXLR8 configure Information Request Types for you. We make sure they have the correct “clock” settings, privacy flags and auto-deletion parameters for your Retention Policy. We have templates ready for most jurisdictions.

Here are three examples from our Demo system. Please also see Request Status which works with Request Types to enable events (e.g. “clarification” or “quotation” or “checking proof of ID” or closure) to stop, pause or reset the “clock” as appropriate.

FOI Request Type

The clock is set to ignore bank holidays. Privacy is not flagged (although, see below for “Sensitive FOI”)

Extended FOI

For those FOI requests that require more time – say 40 days, you can create a variant of the FOI Request Type. The only difference is that it has a 40 day “clock”. If you change from and FOI to an FOI – Extended, the deadline will automatically change. Thus, for example, if you realise, on day 9, that an FOI will be much more work, then you have 11 working days to go. If you simply change the Request Type in the drop down box, then you will automatically see the deadline date change to 31 working days hence. The set up ALR8 apply to this is shown below. Some clients have also asked us for other extensions on Request Types.

SAR Request Type

The clock runs including weekends and bank/public holidays. I.e. it works on Calendar days. It is also “Private“.

Sensitive FOI

This is a Request Type for FOIs that include personal, private content. The clock can still run as an FOI but the “Private” flag is set both internally and externally. The “Public” flag is not set. Some organisations ask AXLR8 to set the DPA flag and treat them fully as if they were SARs. They may be Sensitive FOIs for other reasons.

How configuring a Request Type changes IR lifecycle

How else to these parameters change the way the AXLR8 system manages IRs?

1. Length of time to deadline for response progress tracking
2. Appearance or not on the Public Disclosure Log
3. Colours to distinguish them on reports built with AXLR8 Report Builder
4. Privacy settings for users (most of whom will not see “private” flagged request types.
5. Working days (exclude weekends and public holidays set by your organisation in Bank Holiday Admin) or Calendar days.
6. Whether it is in DPA or FOI or EIR reports and screens
7. How retention automation works
8. …………………..and many more.

It is critical to get the Request Types configured correctly. You can see the implications from the list above. We need to consider every dependency.

If you need any changes to your request types, please contact AXLR8 Support. We will be happy to help. You can read the Request Type Admin area but not make any changes yourself. Your AXLR8 Support consultant will ask you for details and configure and test it across business rules with a programmer.

Information Request Workflow Automation was introduced here as a way to improve productivity for public sector IG Teams. Some Use cases are listed. We show how one of them might be automated and how the User Permissions work to make sure only the correct people design and deploy the robots.

Proof of Identity Workflow Automation

The example below is a abridged schematic of SAR workflow. Obviously, there is much more to it and more detailed workflow charts can be found elsewhere on this site.

Automation steps

Typically, the process building this in to your AXLR8 IRMS starts with your requirements.

1. In Document Template Admin, build the messages for each stage in the medium desired.  Usually these will be emails, SMS Messages or Word documents. For example reminders using Trigaware™ after waiting for a PoID for a SAR.  The messaging can be simple or intelligent with personalisation and very specific conditional contents. (see smart messaging).
2. We set up a “custom event definition” (i.e. the point in your workflow at which you need the document to go to the client).
3. Define the Status Life Cycle: the next section describes how to define a time limit for a status and any status change that follows completion of that life cycle. The life (cycle) of a status is the time it runs for or period before it closes itself and kicks off the new status.

Stage 1 Messaging to match your status change requirement

These examples match the work flow above.

• Inform the applicant that the IG team need this from the applicant when the IR is set to “Clarification Requested”
• Then alert them that 20 days has passed and there are 20 days remaining before they will have to resubmit their request. This would happen when the Clarification Second Request auto launched itself.
• The IR will close when the 40 days end and there has been no Clarification (or PoID). A third Trigger email can be programmed to go out. It would inform the applicant that their IR is now closed. They will have to resubmit it if they still need the information.

Stage 2: Create Automated Information Request

The best way to accomplish your objectives for Information Request automations is to create new IR Statuses. The reason for this is that all existing IRs that are running with that status will suddenly automate. If that is OK with you, go for it. We will describe how you do that below but you should consider the safer route of creating and applying a new one.

Please refer to the screenshots below which show the update of an IR Status and the creation of a new one.
The existing IR Status called “SAR ID Requested” for this client could be upgraded by:

• adding the tick for Time limited Status
• adding a duration of 20 days
• selecting a carry on status (in this case it will “Final SAR Request”)
• ticking the box for Special User Access. (see “User Permissions” below)

So after 20 days from the initial request, the IR is automatically sent to the next status of a final 20 days where they are on notice that the IR will be closed after that period. This is a total of 40 days. Very reasonable if you automate some reminders for the applicant as well.

In the above example, we updated and existing IR Status for our first 20 day SAR Request for PoID. Below we have created a new Information Request Status, also 20 days in duration and the last 20 day period they have in which to prove they are who they say they are before work starts finding their requested information. In the green box, to confirm the process above, we did the same ticks and duration. The difference is that the end of the 20 days automatically changes the status to Cancelled by Requester. Again, your organisation may have different vocabulary. You might call that “Failed to supply PoID” or some other label. In any case, it would close the IR because this final status would be a “finished” status.

So, we now have a “chain” of three actions that will hand over like a relay race with no human intervention necessary until PoID is received and agreed as valid, one day. Then the automated process is stopped and work begins with that request.

NB in the above example, you will see that this IR Status is disabled (tick box at the top). That is because We have not yet applied user permissions (or tested it).

Note. It is best not to apply the time limited status settings to existing IR statuses unless you are confident you know the outcome.  The next time it runs, it would run on all the existing IR records that have that existing status. Do you want that?  If you do make a status time limited, it would be best to search to see how many IR’s have that status, and understand that if they were given it more than the duration number of “valid” days ago, that “it will” change the status next time it runs.

Stage 3. Review User Permissions

Not all users should have the authority or expertise to apply a timed status. They may launch a wrong workflow automation. For example, without knowing the next steps, they could create an infinite loop. Users need to have the new user permission to apply one of these time limited statuses when they are first created. Later, when ta few runs through have proven the automations, you can remove the restriction from the IR status. This is done by removing the “Special User Access” shown in the screenshots in the previous stage. Below is how we can set up a knowledgeable pilot user to be able to use the new timed IR Statuses.

There is a new User Permission. It is called “Can apply Special User Access Statuses”, on user admin. Here is an example from a real client showing where it is on the User Admin screen.

If a User tries to apply a Time Limited IR Status to an Information Request, they may not be able to do so. If they do not have permission, they will get the following message.

For someone with this permission, the above alert message (example from City of Edinburgh) will not appear. That User can save their chosen status.

Systems Admin Permissions

As described above, your Super Users may decide which Users may apply these IR Statuses with timings built in. I.e. the “special User Access” IR statuses.

We have disabled update rights for clients but you have complete visibility of information Request Statuses. You can request an AXLR8 consultant to make the change.  Thus in your office, similar to the Dropdowns admin for Request Type, the Dropdowns Admin for Information Request Status only has a Save function when one of our consultants is using it. 
It is not available from client offices. AXLR8 have retained some of the administrative privileges for our support specialists for Request Status Admin.

The “Save” function in Information Request Status “Dropdowns Admin” was always available for Super Users at our clients. However, the ability to save changes in Request Type was reserved for AXLR8 consultants. The reason was the cost to us of fixing mistakes. With the power of this new Workflow automation we need to work with a few clients to take responsibility and shoulder the expense of any errors before handing back the ability to save changes. We also assume most client Super Users would wish to work over a Teams meeting screenshare with an AXLR8 support consultant when building these IR Automations. The reason is that mistakes can be costly to fix.

Audit Log

In the audit log view we can see the Cancelled status is a “Close” status, the save object has also set the “Date Closed” date (same as if you set the IR to cancelled in the IR details screen).

Why must we update Bank Holiday dates? Some information requests have a response deadline in Calendar Days, e.g. SARs. Others like FOI and EIR must be completed in Working days. These “Request Types” are configured in Request Type Admin.

The AXLR8 system must exclude weekends and public holidays for those Request Types. Request Types change from jurisdiction to jurisdiction and in some countries local areas may differ. So, AXLR8 have a simple solution. We provide a Bank Holiday Admin area where you can manage your organisation’s public holiday dates.

Bank Holiday Admin

The Bank Holiday Admin function is to be found in the Super User menu. It is down at the bottom. The reason is that it is not used very often. You can add a few years in ahead if you wish. Don’t forget a diary date to review them.

You can add (or remove) dates for public holidays. This is shown below.

These days are excluded from the day-count up to the response deadline.

Responsibility for updating Bank Holidays

You, the client, are responsible for keeping your Bank Holidays updated. We enter the pubic holidays for a year with you as part of the Super User Systems Admin training. This is done when we first implement your system.

Occasionally, we find a client who has forgotten to update them after that.

We sometimes ask clients if they would like one of our interns to help. It is a good “work experience” job. This might be whilst working on their system on another support job. In that case, we inform the client. Please do not rely upon it. Set a date in your diary. Once a year should do it. There are too many clients and local variations for AXLR8 to manage it centrally.

Messagestore takes a copy of all relevant email messages that enter and leave your business. For example, you might be set up to take any email to or from foi@yourorganisation.gov.uk and dataprotection@yourorganisation.gov.uk.

Messagestore then files them against the recipients and senders and the information request unique identifiers. The unique identifiers are coded into the subject lines in the email templates and the numbers and short descriptions are mail merged in.

This is described in greater detail together with “use cases”, blogs and articles on the messagestore.co.uk specialist website.

Merging IR references into the email subject line

The subject line of emails can have mailmerged data in them in the same way as you mail merge data into the body of a document.

The mailmerge templates are created and maintained in Document Template Admin.

Messagestore and Email2IR

Messagestore provides the platform for AXLR8’s Email2IR functionality. Email2IR checks Messagestore for any incoming email and creates a new IR ready for human management decisions:

1. request type (or you can clik the “Spam” button) and
2. the applicant (add new or allocate to a previous “frequent flier”).

If there is an exisiting IR reference in the subject line of the incoming email, then that incoming email does not create a new IR. The process checks for whether the email is about an exisiting IRs. It accomplishes this by reading the subject line. If there is and IR code in it, then it will add it to the “job bag” for that IR.

Please call if you need any training on this area or have any concerns about controlling visibility of emails for different groups of users.

Sometimes the original Information Request Type must change. What happens to the Due Date?
The most obvious example is when you log an FOI request thinking it is simple and it turns out to be more complex. It might be that clarification by the applicant expands the scope or the department providing some or all of the expertise explains an unforseen depth and raises more questions than answers.

Example 1: FOI changes to FOI Extended

An FOI request allows you 20 working days to respond. Bank Holidays in your jurisdiction and weekends are excluded. If a request is complex or more time is required, you may be able to extend that response time to 40 working days. In some jurisdictions there may also be 60 day FOI periods.
You can start with an FOI request and realise at some point that it will not be as simple to respond as had originally been thought. Therefore, you can change it to an “FOI Extended” with 40 days to respond. The AXLR8 system will then take the days that have already run and recalculate the new due date and hence the days outstanding wil have 20 days added on.

Let us take a simple example. FOI Request 1234 comes in and is set as an FOI 20 request type. The code indicates that it is and FOI request and has 20 working dats to run. It comes in on 11/04/2025, the day I am writing this FAQ. The due date will become 14/05/2025. Please note I took this from Demoshire2 which is presently set to English Bank Holidays in 2025 ( April 18 & 21, May 5 & 26 and Aug 25th). Assume for now that no restart for Clarification was required.

Let’s say it runs for 5 working days. Now, there are 15 working days left. I decide it is a 40 day FOI request instead. Then the clock will keep the days already used but the due date will be calculated as if it had been a 40 day request in the first place. So, it will change the due date to 12/06/2025. and the countdown will change from 15 days left to 35 days left. You can see why the public holidays were mentioned above!

Example 2: FOI changes to DPA Access then to DPA Access Extended

This was a real query from a client.

“We also have a query about request types changing throughout the request life, and how this changes the due date on requests (e.g. if a request is first thought to be FOISA , then changed to DPA – Access request and then changed to DPA – Access complex).“

We can use this as an example and apply the principles above. Same public holidays for simplicity even though this actually came from a different jurisdiction – Scotland whose bank holidays are different as yours may be. We have applied the rule that a response last day for a DPA/SAR may not fall on a weekend or bank holiday.

NB Please assume that any clarification or proof of ID has taken place beforehand. If it had not, the system would deal with those legitimate delays. It recalculates the Due Date as events take place.

AXLR8 are enhancing the system to work with calendar months. Choosing 28 days is accepted by most jurisdictions ( e.g. OIC). However, our feedback is that clients would prefer precise calendar months. This means that an IG team can complete a request in a 31 day month in 29 or 30 days. KPI reports will not show it as late. This new development is expected soon.

Example 3: May 25th 2018 – introduction of GDPR

The rules all changed for GDPR. AXLR8 just made the SAR requests starting on that Friday morning of the 25th run for a month. This is still the rule. Previously you were allowed 40 calendar days.

Every DPA request logged before midnight on 24th ran through to the end of its 40 day pre-GDPR processing time. So, AXLR8 made this enormous transition without any adverse results or extra charges.

Additional extended periods for more demanding SARS could also be chosen after that time.

Audit Trail

NB the changes made will be in the audit trail and so there is a visible “journey”. You can track how and when, the Coundown and Due Date has changed. It also shows which user made those changes.

KPIs

The Reports will accurately present the statistics. For example, it will show those responses which were late or on time and by how many days.

Questions?

You may have other examples and wish to play them through our system to check them.

Please do not hestiate to ask.

Short answer, anything you want during any timescale you can afford.

However, this is a standard AXLR8 demo of 48 minutes plus questions.

Items such as migration from legacy systems and security and other areas of compliance required in the public sector will be dealt with in depth if required at a later stage.

Other tools

If of interest, we can always look at other IG tools later Data Breach, DPIA, Information Asset Register, Data Sharing Policy Register, etc.  Also, Complaints Processing and other workflows.

AXLR8 configure Information Request Types for you. We make sure they have the correct “clock” settings, privacy flags and auto-deletion parameters for your Retention Policy. We have templates ready for most jurisdictions.

Here are three examples from our Demo system. Please also see Request Status which works with Request Types to enable events (e.g. “clarification” or “quotation” or “checking proof of ID” or closure) to stop, pause or reset the “clock” as appropriate.

FOI Request Type

The clock is set to ignore bank holidays. Privacy is not flagged (although, see below for “Sensitive FOI”)

Extended FOI

For those FOI requests that require more time – say 40 days, you can create a variant of the FOI Request Type. The only difference is that it has a 40 day “clock”. If you change from and FOI to an FOI – Extended, the deadline will automatically change. Thus, for example, if you realise, on day 9, that an FOI will be much more work, then you have 11 working days to go. If you simply change the Request Type in the drop down box, then you will automatically see the deadline date change to 31 working days hence. The set up ALR8 apply to this is shown below. Some clients have also asked us for other extensions on Request Types.

SAR Request Type

The clock runs including weekends and bank/public holidays. I.e. it works on Calendar days. It is also “Private“.

Sensitive FOI

This is a Request Type for FOIs that include personal, private content. The clock can still run as an FOI but the “Private” flag is set both internally and externally. The “Public” flag is not set. Some organisations ask AXLR8 to set the DPA flag and treat them fully as if they were SARs. They may be Sensitive FOIs for other reasons.

How configuring a Request Type changes IR lifecycle

How else to these parameters change the way the AXLR8 system manages IRs?

1. Length of time to deadline for response progress tracking
2. Appearance or not on the Public Disclosure Log
3. Colours to distinguish them on reports built with AXLR8 Report Builder
4. Privacy settings for users (most of whom will not see “private” flagged request types.
5. Working days (exclude weekends and public holidays set by your organisation in Bank Holiday Admin) or Calendar days.
6. Whether it is in DPA or FOI or EIR reports and screens
7. How retention automation works
8. …………………..and many more.

It is critical to get the Request Types configured correctly. You can see the implications from the list above. We need to consider every dependency.

If you need any changes to your request types, please contact AXLR8 Support. We will be happy to help. You can read the Request Type Admin area but not make any changes yourself. Your AXLR8 Support consultant will ask you for details and configure and test it across business rules with a programmer.

Information Request Workflow Automation was introduced here as a way to improve productivity for public sector IG Teams. Some Use cases are listed. We show how one of them might be automated and how the User Permissions work to make sure only the correct people design and deploy the robots.

Proof of Identity Workflow Automation

The example below is a abridged schematic of SAR workflow. Obviously, there is much more to it and more detailed workflow charts can be found elsewhere on this site.

Automation steps

Typically, the process building this in to your AXLR8 IRMS starts with your requirements.

1. In Document Template Admin, build the messages for each stage in the medium desired.  Usually these will be emails, SMS Messages or Word documents. For example reminders using Trigaware™ after waiting for a PoID for a SAR.  The messaging can be simple or intelligent with personalisation and very specific conditional contents. (see smart messaging).
2. We set up a “custom event definition” (i.e. the point in your workflow at which you need the document to go to the client).
3. Define the Status Life Cycle: the next section describes how to define a time limit for a status and any status change that follows completion of that life cycle. The life (cycle) of a status is the time it runs for or period before it closes itself and kicks off the new status.

Stage 1 Messaging to match your status change requirement

These examples match the work flow above.

• Inform the applicant that the IG team need this from the applicant when the IR is set to “Clarification Requested”
• Then alert them that 20 days has passed and there are 20 days remaining before they will have to resubmit their request. This would happen when the Clarification Second Request auto launched itself.
• The IR will close when the 40 days end and there has been no Clarification (or PoID). A third Trigger email can be programmed to go out. It would inform the applicant that their IR is now closed. They will have to resubmit it if they still need the information.

Stage 2: Create Automated Information Request

The best way to accomplish your objectives for Information Request automations is to create new IR Statuses. The reason for this is that all existing IRs that are running with that status will suddenly automate. If that is OK with you, go for it. We will describe how you do that below but you should consider the safer route of creating and applying a new one.

Please refer to the screenshots below which show the update of an IR Status and the creation of a new one.
The existing IR Status called “SAR ID Requested” for this client could be upgraded by:

• adding the tick for Time limited Status
• adding a duration of 20 days
• selecting a carry on status (in this case it will “Final SAR Request”)
• ticking the box for Special User Access. (see “User Permissions” below)

So after 20 days from the initial request, the IR is automatically sent to the next status of a final 20 days where they are on notice that the IR will be closed after that period. This is a total of 40 days. Very reasonable if you automate some reminders for the applicant as well.

In the above example, we updated and existing IR Status for our first 20 day SAR Request for PoID. Below we have created a new Information Request Status, also 20 days in duration and the last 20 day period they have in which to prove they are who they say they are before work starts finding their requested information. In the green box, to confirm the process above, we did the same ticks and duration. The difference is that the end of the 20 days automatically changes the status to Cancelled by Requester. Again, your organisation may have different vocabulary. You might call that “Failed to supply PoID” or some other label. In any case, it would close the IR because this final status would be a “finished” status.

So, we now have a “chain” of three actions that will hand over like a relay race with no human intervention necessary until PoID is received and agreed as valid, one day. Then the automated process is stopped and work begins with that request.

NB in the above example, you will see that this IR Status is disabled (tick box at the top). That is because We have not yet applied user permissions (or tested it).

Note. It is best not to apply the time limited status settings to existing IR statuses unless you are confident you know the outcome.  The next time it runs, it would run on all the existing IR records that have that existing status. Do you want that?  If you do make a status time limited, it would be best to search to see how many IR’s have that status, and understand that if they were given it more than the duration number of “valid” days ago, that “it will” change the status next time it runs.

Stage 3. Review User Permissions

Not all users should have the authority or expertise to apply a timed status. They may launch a wrong workflow automation. For example, without knowing the next steps, they could create an infinite loop. Users need to have the new user permission to apply one of these time limited statuses when they are first created. Later, when ta few runs through have proven the automations, you can remove the restriction from the IR status. This is done by removing the “Special User Access” shown in the screenshots in the previous stage. Below is how we can set up a knowledgeable pilot user to be able to use the new timed IR Statuses.

There is a new User Permission. It is called “Can apply Special User Access Statuses”, on user admin. Here is an example from a real client showing where it is on the User Admin screen.

If a User tries to apply a Time Limited IR Status to an Information Request, they may not be able to do so. If they do not have permission, they will get the following message.

For someone with this permission, the above alert message (example from City of Edinburgh) will not appear. That User can save their chosen status.

Systems Admin Permissions

As described above, your Super Users may decide which Users may apply these IR Statuses with timings built in. I.e. the “special User Access” IR statuses.

We have disabled update rights for clients but you have complete visibility of information Request Statuses. You can request an AXLR8 consultant to make the change.  Thus in your office, similar to the Dropdowns admin for Request Type, the Dropdowns Admin for Information Request Status only has a Save function when one of our consultants is using it. 
It is not available from client offices. AXLR8 have retained some of the administrative privileges for our support specialists for Request Status Admin.

The “Save” function in Information Request Status “Dropdowns Admin” was always available for Super Users at our clients. However, the ability to save changes in Request Type was reserved for AXLR8 consultants. The reason was the cost to us of fixing mistakes. With the power of this new Workflow automation we need to work with a few clients to take responsibility and shoulder the expense of any errors before handing back the ability to save changes. We also assume most client Super Users would wish to work over a Teams meeting screenshare with an AXLR8 support consultant when building these IR Automations. The reason is that mistakes can be costly to fix.

Audit Log

In the audit log view we can see the Cancelled status is a “Close” status, the save object has also set the “Date Closed” date (same as if you set the IR to cancelled in the IR details screen).

Why must we update Bank Holiday dates? Some information requests have a response deadline in Calendar Days, e.g. SARs. Others like FOI and EIR must be completed in Working days. These “Request Types” are configured in Request Type Admin.

The AXLR8 system must exclude weekends and public holidays for those Request Types. Request Types change from jurisdiction to jurisdiction and in some countries local areas may differ. So, AXLR8 have a simple solution. We provide a Bank Holiday Admin area where you can manage your organisation’s public holiday dates.

Bank Holiday Admin

The Bank Holiday Admin function is to be found in the Super User menu. It is down at the bottom. The reason is that it is not used very often. You can add a few years in ahead if you wish. Don’t forget a diary date to review them.

You can add (or remove) dates for public holidays. This is shown below.

These days are excluded from the day-count up to the response deadline.

Responsibility for updating Bank Holidays

You, the client, are responsible for keeping your Bank Holidays updated. We enter the pubic holidays for a year with you as part of the Super User Systems Admin training. This is done when we first implement your system.

Occasionally, we find a client who has forgotten to update them after that.

We sometimes ask clients if they would like one of our interns to help. It is a good “work experience” job. This might be whilst working on their system on another support job. In that case, we inform the client. Please do not rely upon it. Set a date in your diary. Once a year should do it. There are too many clients and local variations for AXLR8 to manage it centrally.

Sometimes the original Information Request Type must change. What happens to the Due Date?
The most obvious example is when you log an FOI request thinking it is simple and it turns out to be more complex. It might be that clarification by the applicant expands the scope or the department providing some or all of the expertise explains an unforseen depth and raises more questions than answers.

Example 1: FOI changes to FOI Extended

An FOI request allows you 20 working days to respond. Bank Holidays in your jurisdiction and weekends are excluded. If a request is complex or more time is required, you may be able to extend that response time to 40 working days. In some jurisdictions there may also be 60 day FOI periods.
You can start with an FOI request and realise at some point that it will not be as simple to respond as had originally been thought. Therefore, you can change it to an “FOI Extended” with 40 days to respond. The AXLR8 system will then take the days that have already run and recalculate the new due date and hence the days outstanding wil have 20 days added on.

Let us take a simple example. FOI Request 1234 comes in and is set as an FOI 20 request type. The code indicates that it is and FOI request and has 20 working dats to run. It comes in on 11/04/2025, the day I am writing this FAQ. The due date will become 14/05/2025. Please note I took this from Demoshire2 which is presently set to English Bank Holidays in 2025 ( April 18 & 21, May 5 & 26 and Aug 25th). Assume for now that no restart for Clarification was required.

Let’s say it runs for 5 working days. Now, there are 15 working days left. I decide it is a 40 day FOI request instead. Then the clock will keep the days already used but the due date will be calculated as if it had been a 40 day request in the first place. So, it will change the due date to 12/06/2025. and the countdown will change from 15 days left to 35 days left. You can see why the public holidays were mentioned above!

Example 2: FOI changes to DPA Access then to DPA Access Extended

This was a real query from a client.

“We also have a query about request types changing throughout the request life, and how this changes the due date on requests (e.g. if a request is first thought to be FOISA , then changed to DPA – Access request and then changed to DPA – Access complex).“

We can use this as an example and apply the principles above. Same public holidays for simplicity even though this actually came from a different jurisdiction – Scotland whose bank holidays are different as yours may be. We have applied the rule that a response last day for a DPA/SAR may not fall on a weekend or bank holiday.

NB Please assume that any clarification or proof of ID has taken place beforehand. If it had not, the system would deal with those legitimate delays. It recalculates the Due Date as events take place.

AXLR8 are enhancing the system to work with calendar months. Choosing 28 days is accepted by most jurisdictions ( e.g. OIC). However, our feedback is that clients would prefer precise calendar months. This means that an IG team can complete a request in a 31 day month in 29 or 30 days. KPI reports will not show it as late. This new development is expected soon.

Example 3: May 25th 2018 – introduction of GDPR

The rules all changed for GDPR. AXLR8 just made the SAR requests starting on that Friday morning of the 25th run for a month. This is still the rule. Previously you were allowed 40 calendar days.

Every DPA request logged before midnight on 24th ran through to the end of its 40 day pre-GDPR processing time. So, AXLR8 made this enormous transition without any adverse results or extra charges.

Additional extended periods for more demanding SARS could also be chosen after that time.

Audit Trail

NB the changes made will be in the audit trail and so there is a visible “journey”. You can track how and when, the Coundown and Due Date has changed. It also shows which user made those changes.

KPIs

The Reports will accurately present the statistics. For example, it will show those responses which were late or on time and by how many days.

Questions?

You may have other examples and wish to play them through our system to check them.

Please do not hestiate to ask.

Short answer, anything you want during any timescale you can afford.

However, this is a standard AXLR8 demo of 48 minutes plus questions.

Items such as migration from legacy systems and security and other areas of compliance required in the public sector will be dealt with in depth if required at a later stage.

Other tools

If of interest, we can always look at other IG tools later Data Breach, DPIA, Information Asset Register, Data Sharing Policy Register, etc.  Also, Complaints Processing and other workflows.

AXLR8 configure Information Request Types for you. We make sure they have the correct “clock” settings, privacy flags and auto-deletion parameters for your Retention Policy. We have templates ready for most jurisdictions.

Here are three examples from our Demo system. Please also see Request Status which works with Request Types to enable events (e.g. “clarification” or “quotation” or “checking proof of ID” or closure) to stop, pause or reset the “clock” as appropriate.

FOI Request Type

The clock is set to ignore bank holidays. Privacy is not flagged (although, see below for “Sensitive FOI”)

Extended FOI

For those FOI requests that require more time – say 40 days, you can create a variant of the FOI Request Type. The only difference is that it has a 40 day “clock”. If you change from and FOI to an FOI – Extended, the deadline will automatically change. Thus, for example, if you realise, on day 9, that an FOI will be much more work, then you have 11 working days to go. If you simply change the Request Type in the drop down box, then you will automatically see the deadline date change to 31 working days hence. The set up ALR8 apply to this is shown below. Some clients have also asked us for other extensions on Request Types.

SAR Request Type

The clock runs including weekends and bank/public holidays. I.e. it works on Calendar days. It is also “Private“.

Sensitive FOI

This is a Request Type for FOIs that include personal, private content. The clock can still run as an FOI but the “Private” flag is set both internally and externally. The “Public” flag is not set. Some organisations ask AXLR8 to set the DPA flag and treat them fully as if they were SARs. They may be Sensitive FOIs for other reasons.

How configuring a Request Type changes IR lifecycle

How else to these parameters change the way the AXLR8 system manages IRs?

1. Length of time to deadline for response progress tracking
2. Appearance or not on the Public Disclosure Log
3. Colours to distinguish them on reports built with AXLR8 Report Builder
4. Privacy settings for users (most of whom will not see “private” flagged request types.
5. Working days (exclude weekends and public holidays set by your organisation in Bank Holiday Admin) or Calendar days.
6. Whether it is in DPA or FOI or EIR reports and screens
7. How retention automation works
8. …………………..and many more.

It is critical to get the Request Types configured correctly. You can see the implications from the list above. We need to consider every dependency.

If you need any changes to your request types, please contact AXLR8 Support. We will be happy to help. You can read the Request Type Admin area but not make any changes yourself. Your AXLR8 Support consultant will ask you for details and configure and test it across business rules with a programmer.

This is accomplished in Document Template Admin.
To find Document Template Admin, please select Admin menu (cog on LHS menu in the old system or Super User menu in the new UX). Then select Document Template Admin.
There you will see a list of documents already available.

Medium

• Letter
• Email
• Text (SMS) Message
• Other

File Types

The format of the email will allow it to present and send in diferent ways.

• .RTF that can be opened by a wide variety of document readers including MS Word
• .HTML for formatted emails with colours and different highlights, fonts, embedded hyperlinks
• .TXT for plain text emails
• other

Context

A mailing template may be built to work in various different contexts.

• Contact person only (name address, etc.)
  • Reviews and appeals
• Information Request where the dates (including due date), short descriptions, subject, exemptions, department, owners and applicants and much more information may be merged in specific to that IR.
• Activity (task within an activity with a specific owner or team to respond in a department
• Breach

Subject Line

The subject line determines ti a significan extent whether an email will be opened. You can mail merge fields of data into the subject line of your email template.

The scope for automation of tasks is enormous with smart mail merged correspondence available in a couple of clicks.

The documents created are also auto-attached to the Information Request. If you have AXLR8 Messagestore then incoming and outgoing emails will be stored against the Information Request, too.

Trigaware

There are also fully automated emails. These are in addition to the mail merged documents. They are launched by the AXLR8 Trigaware system which are preprogrammed on events. Examples include:

• auto acknowledgement to applicants including details of their request and the due date
• alert to the team handling responses
• reminders at 10 and 5 days before the due date for those esponsible
• alert when a department officer has added a File or Note to an Information Request.

Some clients have a two dozen of these set up containing alerts that change with conditions.

Trigaware auto emails are explained at length elsewhere.

Information Request Workflow Automation was introduced here as a way to improve productivity for public sector IG Teams. Some Use cases are listed. We show how one of them might be automated and how the User Permissions work to make sure only the correct people design and deploy the robots.

Proof of Identity Workflow Automation

The example below is a abridged schematic of SAR workflow. Obviously, there is much more to it and more detailed workflow charts can be found elsewhere on this site.

Automation steps

Typically, the process building this in to your AXLR8 IRMS starts with your requirements.

1. In Document Template Admin, build the messages for each stage in the medium desired.  Usually these will be emails, SMS Messages or Word documents. For example reminders using Trigaware™ after waiting for a PoID for a SAR.  The messaging can be simple or intelligent with personalisation and very specific conditional contents. (see smart messaging).
2. We set up a “custom event definition” (i.e. the point in your workflow at which you need the document to go to the client).
3. Define the Status Life Cycle: the next section describes how to define a time limit for a status and any status change that follows completion of that life cycle. The life (cycle) of a status is the time it runs for or period before it closes itself and kicks off the new status.

Stage 1 Messaging to match your status change requirement

These examples match the work flow above.

• Inform the applicant that the IG team need this from the applicant when the IR is set to “Clarification Requested”
• Then alert them that 20 days has passed and there are 20 days remaining before they will have to resubmit their request. This would happen when the Clarification Second Request auto launched itself.
• The IR will close when the 40 days end and there has been no Clarification (or PoID). A third Trigger email can be programmed to go out. It would inform the applicant that their IR is now closed. They will have to resubmit it if they still need the information.

Stage 2: Create Automated Information Request

The best way to accomplish your objectives for Information Request automations is to create new IR Statuses. The reason for this is that all existing IRs that are running with that status will suddenly automate. If that is OK with you, go for it. We will describe how you do that below but you should consider the safer route of creating and applying a new one.

Please refer to the screenshots below which show the update of an IR Status and the creation of a new one.
The existing IR Status called “SAR ID Requested” for this client could be upgraded by:

• adding the tick for Time limited Status
• adding a duration of 20 days
• selecting a carry on status (in this case it will “Final SAR Request”)
• ticking the box for Special User Access. (see “User Permissions” below)

So after 20 days from the initial request, the IR is automatically sent to the next status of a final 20 days where they are on notice that the IR will be closed after that period. This is a total of 40 days. Very reasonable if you automate some reminders for the applicant as well.

In the above example, we updated and existing IR Status for our first 20 day SAR Request for PoID. Below we have created a new Information Request Status, also 20 days in duration and the last 20 day period they have in which to prove they are who they say they are before work starts finding their requested information. In the green box, to confirm the process above, we did the same ticks and duration. The difference is that the end of the 20 days automatically changes the status to Cancelled by Requester. Again, your organisation may have different vocabulary. You might call that “Failed to supply PoID” or some other label. In any case, it would close the IR because this final status would be a “finished” status.

So, we now have a “chain” of three actions that will hand over like a relay race with no human intervention necessary until PoID is received and agreed as valid, one day. Then the automated process is stopped and work begins with that request.

NB in the above example, you will see that this IR Status is disabled (tick box at the top). That is because We have not yet applied user permissions (or tested it).

Note. It is best not to apply the time limited status settings to existing IR statuses unless you are confident you know the outcome.  The next time it runs, it would run on all the existing IR records that have that existing status. Do you want that?  If you do make a status time limited, it would be best to search to see how many IR’s have that status, and understand that if they were given it more than the duration number of “valid” days ago, that “it will” change the status next time it runs.

Stage 3. Review User Permissions

Not all users should have the authority or expertise to apply a timed status. They may launch a wrong workflow automation. For example, without knowing the next steps, they could create an infinite loop. Users need to have the new user permission to apply one of these time limited statuses when they are first created. Later, when ta few runs through have proven the automations, you can remove the restriction from the IR status. This is done by removing the “Special User Access” shown in the screenshots in the previous stage. Below is how we can set up a knowledgeable pilot user to be able to use the new timed IR Statuses.

There is a new User Permission. It is called “Can apply Special User Access Statuses”, on user admin. Here is an example from a real client showing where it is on the User Admin screen.

If a User tries to apply a Time Limited IR Status to an Information Request, they may not be able to do so. If they do not have permission, they will get the following message.

For someone with this permission, the above alert message (example from City of Edinburgh) will not appear. That User can save their chosen status.

Systems Admin Permissions

As described above, your Super Users may decide which Users may apply these IR Statuses with timings built in. I.e. the “special User Access” IR statuses.

We have disabled update rights for clients but you have complete visibility of information Request Statuses. You can request an AXLR8 consultant to make the change.  Thus in your office, similar to the Dropdowns admin for Request Type, the Dropdowns Admin for Information Request Status only has a Save function when one of our consultants is using it. 
It is not available from client offices. AXLR8 have retained some of the administrative privileges for our support specialists for Request Status Admin.

The “Save” function in Information Request Status “Dropdowns Admin” was always available for Super Users at our clients. However, the ability to save changes in Request Type was reserved for AXLR8 consultants. The reason was the cost to us of fixing mistakes. With the power of this new Workflow automation we need to work with a few clients to take responsibility and shoulder the expense of any errors before handing back the ability to save changes. We also assume most client Super Users would wish to work over a Teams meeting screenshare with an AXLR8 support consultant when building these IR Automations. The reason is that mistakes can be costly to fix.

Audit Log

In the audit log view we can see the Cancelled status is a “Close” status, the save object has also set the “Date Closed” date (same as if you set the IR to cancelled in the IR details screen).

Messagestore takes a copy of all relevant email messages that enter and leave your business. For example, you might be set up to take any email to or from foi@yourorganisation.gov.uk and dataprotection@yourorganisation.gov.uk.

Messagestore then files them against the recipients and senders and the information request unique identifiers. The unique identifiers are coded into the subject lines in the email templates and the numbers and short descriptions are mail merged in.

This is described in greater detail together with “use cases”, blogs and articles on the messagestore.co.uk specialist website.

Merging IR references into the email subject line

The subject line of emails can have mailmerged data in them in the same way as you mail merge data into the body of a document.

The mailmerge templates are created and maintained in Document Template Admin.

Messagestore and Email2IR

Messagestore provides the platform for AXLR8’s Email2IR functionality. Email2IR checks Messagestore for any incoming email and creates a new IR ready for human management decisions:

1. request type (or you can clik the “Spam” button) and
2. the applicant (add new or allocate to a previous “frequent flier”).

If there is an exisiting IR reference in the subject line of the incoming email, then that incoming email does not create a new IR. The process checks for whether the email is about an exisiting IRs. It accomplishes this by reading the subject line. If there is and IR code in it, then it will add it to the “job bag” for that IR.

Please call if you need any training on this area or have any concerns about controlling visibility of emails for different groups of users.

Short answer, anything you want during any timescale you can afford.

However, this is a standard AXLR8 demo of 48 minutes plus questions.

Items such as migration from legacy systems and security and other areas of compliance required in the public sector will be dealt with in depth if required at a later stage.

Other tools

If of interest, we can always look at other IG tools later Data Breach, DPIA, Information Asset Register, Data Sharing Policy Register, etc.  Also, Complaints Processing and other workflows.

AXLR8 configure Information Request Types for you. We make sure they have the correct “clock” settings, privacy flags and auto-deletion parameters for your Retention Policy. We have templates ready for most jurisdictions.

Here are three examples from our Demo system. Please also see Request Status which works with Request Types to enable events (e.g. “clarification” or “quotation” or “checking proof of ID” or closure) to stop, pause or reset the “clock” as appropriate.

FOI Request Type

The clock is set to ignore bank holidays. Privacy is not flagged (although, see below for “Sensitive FOI”)

Extended FOI

For those FOI requests that require more time – say 40 days, you can create a variant of the FOI Request Type. The only difference is that it has a 40 day “clock”. If you change from and FOI to an FOI – Extended, the deadline will automatically change. Thus, for example, if you realise, on day 9, that an FOI will be much more work, then you have 11 working days to go. If you simply change the Request Type in the drop down box, then you will automatically see the deadline date change to 31 working days hence. The set up ALR8 apply to this is shown below. Some clients have also asked us for other extensions on Request Types.

SAR Request Type

The clock runs including weekends and bank/public holidays. I.e. it works on Calendar days. It is also “Private“.

Sensitive FOI

This is a Request Type for FOIs that include personal, private content. The clock can still run as an FOI but the “Private” flag is set both internally and externally. The “Public” flag is not set. Some organisations ask AXLR8 to set the DPA flag and treat them fully as if they were SARs. They may be Sensitive FOIs for other reasons.

How configuring a Request Type changes IR lifecycle

How else to these parameters change the way the AXLR8 system manages IRs?

1. Length of time to deadline for response progress tracking
2. Appearance or not on the Public Disclosure Log
3. Colours to distinguish them on reports built with AXLR8 Report Builder
4. Privacy settings for users (most of whom will not see “private” flagged request types.
5. Working days (exclude weekends and public holidays set by your organisation in Bank Holiday Admin) or Calendar days.
6. Whether it is in DPA or FOI or EIR reports and screens
7. How retention automation works
8. …………………..and many more.

It is critical to get the Request Types configured correctly. You can see the implications from the list above. We need to consider every dependency.

If you need any changes to your request types, please contact AXLR8 Support. We will be happy to help. You can read the Request Type Admin area but not make any changes yourself. Your AXLR8 Support consultant will ask you for details and configure and test it across business rules with a programmer.

Information Request Workflow Automation was introduced here as a way to improve productivity for public sector IG Teams. Some Use cases are listed. We show how one of them might be automated and how the User Permissions work to make sure only the correct people design and deploy the robots.

Proof of Identity Workflow Automation

The example below is a abridged schematic of SAR workflow. Obviously, there is much more to it and more detailed workflow charts can be found elsewhere on this site.

Automation steps

Typically, the process building this in to your AXLR8 IRMS starts with your requirements.

1. In Document Template Admin, build the messages for each stage in the medium desired.  Usually these will be emails, SMS Messages or Word documents. For example reminders using Trigaware™ after waiting for a PoID for a SAR.  The messaging can be simple or intelligent with personalisation and very specific conditional contents. (see smart messaging).
2. We set up a “custom event definition” (i.e. the point in your workflow at which you need the document to go to the client).
3. Define the Status Life Cycle: the next section describes how to define a time limit for a status and any status change that follows completion of that life cycle. The life (cycle) of a status is the time it runs for or period before it closes itself and kicks off the new status.

Stage 1 Messaging to match your status change requirement

These examples match the work flow above.

• Inform the applicant that the IG team need this from the applicant when the IR is set to “Clarification Requested”
• Then alert them that 20 days has passed and there are 20 days remaining before they will have to resubmit their request. This would happen when the Clarification Second Request auto launched itself.
• The IR will close when the 40 days end and there has been no Clarification (or PoID). A third Trigger email can be programmed to go out. It would inform the applicant that their IR is now closed. They will have to resubmit it if they still need the information.

Stage 2: Create Automated Information Request

The best way to accomplish your objectives for Information Request automations is to create new IR Statuses. The reason for this is that all existing IRs that are running with that status will suddenly automate. If that is OK with you, go for it. We will describe how you do that below but you should consider the safer route of creating and applying a new one.

Please refer to the screenshots below which show the update of an IR Status and the creation of a new one.
The existing IR Status called “SAR ID Requested” for this client could be upgraded by:

• adding the tick for Time limited Status
• adding a duration of 20 days
• selecting a carry on status (in this case it will “Final SAR Request”)
• ticking the box for Special User Access. (see “User Permissions” below)

So after 20 days from the initial request, the IR is automatically sent to the next status of a final 20 days where they are on notice that the IR will be closed after that period. This is a total of 40 days. Very reasonable if you automate some reminders for the applicant as well.

In the above example, we updated and existing IR Status for our first 20 day SAR Request for PoID. Below we have created a new Information Request Status, also 20 days in duration and the last 20 day period they have in which to prove they are who they say they are before work starts finding their requested information. In the green box, to confirm the process above, we did the same ticks and duration. The difference is that the end of the 20 days automatically changes the status to Cancelled by Requester. Again, your organisation may have different vocabulary. You might call that “Failed to supply PoID” or some other label. In any case, it would close the IR because this final status would be a “finished” status.

So, we now have a “chain” of three actions that will hand over like a relay race with no human intervention necessary until PoID is received and agreed as valid, one day. Then the automated process is stopped and work begins with that request.

NB in the above example, you will see that this IR Status is disabled (tick box at the top). That is because We have not yet applied user permissions (or tested it).

Note. It is best not to apply the time limited status settings to existing IR statuses unless you are confident you know the outcome.  The next time it runs, it would run on all the existing IR records that have that existing status. Do you want that?  If you do make a status time limited, it would be best to search to see how many IR’s have that status, and understand that if they were given it more than the duration number of “valid” days ago, that “it will” change the status next time it runs.

Stage 3. Review User Permissions

Not all users should have the authority or expertise to apply a timed status. They may launch a wrong workflow automation. For example, without knowing the next steps, they could create an infinite loop. Users need to have the new user permission to apply one of these time limited statuses when they are first created. Later, when ta few runs through have proven the automations, you can remove the restriction from the IR status. This is done by removing the “Special User Access” shown in the screenshots in the previous stage. Below is how we can set up a knowledgeable pilot user to be able to use the new timed IR Statuses.

There is a new User Permission. It is called “Can apply Special User Access Statuses”, on user admin. Here is an example from a real client showing where it is on the User Admin screen.

If a User tries to apply a Time Limited IR Status to an Information Request, they may not be able to do so. If they do not have permission, they will get the following message.

For someone with this permission, the above alert message (example from City of Edinburgh) will not appear. That User can save their chosen status.

Systems Admin Permissions

As described above, your Super Users may decide which Users may apply these IR Statuses with timings built in. I.e. the “special User Access” IR statuses.

We have disabled update rights for clients but you have complete visibility of information Request Statuses. You can request an AXLR8 consultant to make the change.  Thus in your office, similar to the Dropdowns admin for Request Type, the Dropdowns Admin for Information Request Status only has a Save function when one of our consultants is using it. 
It is not available from client offices. AXLR8 have retained some of the administrative privileges for our support specialists for Request Status Admin.

The “Save” function in Information Request Status “Dropdowns Admin” was always available for Super Users at our clients. However, the ability to save changes in Request Type was reserved for AXLR8 consultants. The reason was the cost to us of fixing mistakes. With the power of this new Workflow automation we need to work with a few clients to take responsibility and shoulder the expense of any errors before handing back the ability to save changes. We also assume most client Super Users would wish to work over a Teams meeting screenshare with an AXLR8 support consultant when building these IR Automations. The reason is that mistakes can be costly to fix.

Audit Log

In the audit log view we can see the Cancelled status is a “Close” status, the save object has also set the “Date Closed” date (same as if you set the IR to cancelled in the IR details screen).

Why must we update Bank Holiday dates? Some information requests have a response deadline in Calendar Days, e.g. SARs. Others like FOI and EIR must be completed in Working days. These “Request Types” are configured in Request Type Admin.

The AXLR8 system must exclude weekends and public holidays for those Request Types. Request Types change from jurisdiction to jurisdiction and in some countries local areas may differ. So, AXLR8 have a simple solution. We provide a Bank Holiday Admin area where you can manage your organisation’s public holiday dates.

Bank Holiday Admin

The Bank Holiday Admin function is to be found in the Super User menu. It is down at the bottom. The reason is that it is not used very often. You can add a few years in ahead if you wish. Don’t forget a diary date to review them.

You can add (or remove) dates for public holidays. This is shown below.

These days are excluded from the day-count up to the response deadline.

Responsibility for updating Bank Holidays

You, the client, are responsible for keeping your Bank Holidays updated. We enter the pubic holidays for a year with you as part of the Super User Systems Admin training. This is done when we first implement your system.

Occasionally, we find a client who has forgotten to update them after that.

We sometimes ask clients if they would like one of our interns to help. It is a good “work experience” job. This might be whilst working on their system on another support job. In that case, we inform the client. Please do not rely upon it. Set a date in your diary. Once a year should do it. There are too many clients and local variations for AXLR8 to manage it centrally.

Sometimes the original Information Request Type must change. What happens to the Due Date?
The most obvious example is when you log an FOI request thinking it is simple and it turns out to be more complex. It might be that clarification by the applicant expands the scope or the department providing some or all of the expertise explains an unforseen depth and raises more questions than answers.

Example 1: FOI changes to FOI Extended

An FOI request allows you 20 working days to respond. Bank Holidays in your jurisdiction and weekends are excluded. If a request is complex or more time is required, you may be able to extend that response time to 40 working days. In some jurisdictions there may also be 60 day FOI periods.
You can start with an FOI request and realise at some point that it will not be as simple to respond as had originally been thought. Therefore, you can change it to an “FOI Extended” with 40 days to respond. The AXLR8 system will then take the days that have already run and recalculate the new due date and hence the days outstanding wil have 20 days added on.

Let us take a simple example. FOI Request 1234 comes in and is set as an FOI 20 request type. The code indicates that it is and FOI request and has 20 working dats to run. It comes in on 11/04/2025, the day I am writing this FAQ. The due date will become 14/05/2025. Please note I took this from Demoshire2 which is presently set to English Bank Holidays in 2025 ( April 18 & 21, May 5 & 26 and Aug 25th). Assume for now that no restart for Clarification was required.

Let’s say it runs for 5 working days. Now, there are 15 working days left. I decide it is a 40 day FOI request instead. Then the clock will keep the days already used but the due date will be calculated as if it had been a 40 day request in the first place. So, it will change the due date to 12/06/2025. and the countdown will change from 15 days left to 35 days left. You can see why the public holidays were mentioned above!

Example 2: FOI changes to DPA Access then to DPA Access Extended

This was a real query from a client.

“We also have a query about request types changing throughout the request life, and how this changes the due date on requests (e.g. if a request is first thought to be FOISA , then changed to DPA – Access request and then changed to DPA – Access complex).“

We can use this as an example and apply the principles above. Same public holidays for simplicity even though this actually came from a different jurisdiction – Scotland whose bank holidays are different as yours may be. We have applied the rule that a response last day for a DPA/SAR may not fall on a weekend or bank holiday.

NB Please assume that any clarification or proof of ID has taken place beforehand. If it had not, the system would deal with those legitimate delays. It recalculates the Due Date as events take place.

AXLR8 are enhancing the system to work with calendar months. Choosing 28 days is accepted by most jurisdictions ( e.g. OIC). However, our feedback is that clients would prefer precise calendar months. This means that an IG team can complete a request in a 31 day month in 29 or 30 days. KPI reports will not show it as late. This new development is expected soon.

Example 3: May 25th 2018 – introduction of GDPR

The rules all changed for GDPR. AXLR8 just made the SAR requests starting on that Friday morning of the 25th run for a month. This is still the rule. Previously you were allowed 40 calendar days.

Every DPA request logged before midnight on 24th ran through to the end of its 40 day pre-GDPR processing time. So, AXLR8 made this enormous transition without any adverse results or extra charges.

Additional extended periods for more demanding SARS could also be chosen after that time.

Audit Trail

NB the changes made will be in the audit trail and so there is a visible “journey”. You can track how and when, the Coundown and Due Date has changed. It also shows which user made those changes.

KPIs

The Reports will accurately present the statistics. For example, it will show those responses which were late or on time and by how many days.

Questions?

You may have other examples and wish to play them through our system to check them.

Please do not hestiate to ask.

Short answer, anything you want during any timescale you can afford.

However, this is a standard AXLR8 demo of 48 minutes plus questions.

Items such as migration from legacy systems and security and other areas of compliance required in the public sector will be dealt with in depth if required at a later stage.

Other tools

If of interest, we can always look at other IG tools later Data Breach, DPIA, Information Asset Register, Data Sharing Policy Register, etc.  Also, Complaints Processing and other workflows.

AXLR8 configure Information Request Types for you. We make sure they have the correct “clock” settings, privacy flags and auto-deletion parameters for your Retention Policy. We have templates ready for most jurisdictions.

Here are three examples from our Demo system. Please also see Request Status which works with Request Types to enable events (e.g. “clarification” or “quotation” or “checking proof of ID” or closure) to stop, pause or reset the “clock” as appropriate.

FOI Request Type

The clock is set to ignore bank holidays. Privacy is not flagged (although, see below for “Sensitive FOI”)

Extended FOI

For those FOI requests that require more time – say 40 days, you can create a variant of the FOI Request Type. The only difference is that it has a 40 day “clock”. If you change from and FOI to an FOI – Extended, the deadline will automatically change. Thus, for example, if you realise, on day 9, that an FOI will be much more work, then you have 11 working days to go. If you simply change the Request Type in the drop down box, then you will automatically see the deadline date change to 31 working days hence. The set up ALR8 apply to this is shown below. Some clients have also asked us for other extensions on Request Types.

SAR Request Type

The clock runs including weekends and bank/public holidays. I.e. it works on Calendar days. It is also “Private“.

Sensitive FOI

This is a Request Type for FOIs that include personal, private content. The clock can still run as an FOI but the “Private” flag is set both internally and externally. The “Public” flag is not set. Some organisations ask AXLR8 to set the DPA flag and treat them fully as if they were SARs. They may be Sensitive FOIs for other reasons.

How configuring a Request Type changes IR lifecycle

How else to these parameters change the way the AXLR8 system manages IRs?

1. Length of time to deadline for response progress tracking
2. Appearance or not on the Public Disclosure Log
3. Colours to distinguish them on reports built with AXLR8 Report Builder
4. Privacy settings for users (most of whom will not see “private” flagged request types.
5. Working days (exclude weekends and public holidays set by your organisation in Bank Holiday Admin) or Calendar days.
6. Whether it is in DPA or FOI or EIR reports and screens
7. How retention automation works
8. …………………..and many more.

It is critical to get the Request Types configured correctly. You can see the implications from the list above. We need to consider every dependency.

If you need any changes to your request types, please contact AXLR8 Support. We will be happy to help. You can read the Request Type Admin area but not make any changes yourself. Your AXLR8 Support consultant will ask you for details and configure and test it across business rules with a programmer.

Information Request Workflow Automation was introduced here as a way to improve productivity for public sector IG Teams. Some Use cases are listed. We show how one of them might be automated and how the User Permissions work to make sure only the correct people design and deploy the robots.

Proof of Identity Workflow Automation

The example below is a abridged schematic of SAR workflow. Obviously, there is much more to it and more detailed workflow charts can be found elsewhere on this site.

Automation steps

Typically, the process building this in to your AXLR8 IRMS starts with your requirements.

1. In Document Template Admin, build the messages for each stage in the medium desired.  Usually these will be emails, SMS Messages or Word documents. For example reminders using Trigaware™ after waiting for a PoID for a SAR.  The messaging can be simple or intelligent with personalisation and very specific conditional contents. (see smart messaging).
2. We set up a “custom event definition” (i.e. the point in your workflow at which you need the document to go to the client).
3. Define the Status Life Cycle: the next section describes how to define a time limit for a status and any status change that follows completion of that life cycle. The life (cycle) of a status is the time it runs for or period before it closes itself and kicks off the new status.

Stage 1 Messaging to match your status change requirement

These examples match the work flow above.

• Inform the applicant that the IG team need this from the applicant when the IR is set to “Clarification Requested”
• Then alert them that 20 days has passed and there are 20 days remaining before they will have to resubmit their request. This would happen when the Clarification Second Request auto launched itself.
• The IR will close when the 40 days end and there has been no Clarification (or PoID). A third Trigger email can be programmed to go out. It would inform the applicant that their IR is now closed. They will have to resubmit it if they still need the information.

Stage 2: Create Automated Information Request

The best way to accomplish your objectives for Information Request automations is to create new IR Statuses. The reason for this is that all existing IRs that are running with that status will suddenly automate. If that is OK with you, go for it. We will describe how you do that below but you should consider the safer route of creating and applying a new one.

Please refer to the screenshots below which show the update of an IR Status and the creation of a new one.
The existing IR Status called “SAR ID Requested” for this client could be upgraded by:

• adding the tick for Time limited Status
• adding a duration of 20 days
• selecting a carry on status (in this case it will “Final SAR Request”)
• ticking the box for Special User Access. (see “User Permissions” below)

So after 20 days from the initial request, the IR is automatically sent to the next status of a final 20 days where they are on notice that the IR will be closed after that period. This is a total of 40 days. Very reasonable if you automate some reminders for the applicant as well.

In the above example, we updated and existing IR Status for our first 20 day SAR Request for PoID. Below we have created a new Information Request Status, also 20 days in duration and the last 20 day period they have in which to prove they are who they say they are before work starts finding their requested information. In the green box, to confirm the process above, we did the same ticks and duration. The difference is that the end of the 20 days automatically changes the status to Cancelled by Requester. Again, your organisation may have different vocabulary. You might call that “Failed to supply PoID” or some other label. In any case, it would close the IR because this final status would be a “finished” status.

So, we now have a “chain” of three actions that will hand over like a relay race with no human intervention necessary until PoID is received and agreed as valid, one day. Then the automated process is stopped and work begins with that request.

NB in the above example, you will see that this IR Status is disabled (tick box at the top). That is because We have not yet applied user permissions (or tested it).

Note. It is best not to apply the time limited status settings to existing IR statuses unless you are confident you know the outcome.  The next time it runs, it would run on all the existing IR records that have that existing status. Do you want that?  If you do make a status time limited, it would be best to search to see how many IR’s have that status, and understand that if they were given it more than the duration number of “valid” days ago, that “it will” change the status next time it runs.

Stage 3. Review User Permissions

Not all users should have the authority or expertise to apply a timed status. They may launch a wrong workflow automation. For example, without knowing the next steps, they could create an infinite loop. Users need to have the new user permission to apply one of these time limited statuses when they are first created. Later, when ta few runs through have proven the automations, you can remove the restriction from the IR status. This is done by removing the “Special User Access” shown in the screenshots in the previous stage. Below is how we can set up a knowledgeable pilot user to be able to use the new timed IR Statuses.

There is a new User Permission. It is called “Can apply Special User Access Statuses”, on user admin. Here is an example from a real client showing where it is on the User Admin screen.

If a User tries to apply a Time Limited IR Status to an Information Request, they may not be able to do so. If they do not have permission, they will get the following message.

For someone with this permission, the above alert message (example from City of Edinburgh) will not appear. That User can save their chosen status.

Systems Admin Permissions

As described above, your Super Users may decide which Users may apply these IR Statuses with timings built in. I.e. the “special User Access” IR statuses.

We have disabled update rights for clients but you have complete visibility of information Request Statuses. You can request an AXLR8 consultant to make the change.  Thus in your office, similar to the Dropdowns admin for Request Type, the Dropdowns Admin for Information Request Status only has a Save function when one of our consultants is using it. 
It is not available from client offices. AXLR8 have retained some of the administrative privileges for our support specialists for Request Status Admin.

The “Save” function in Information Request Status “Dropdowns Admin” was always available for Super Users at our clients. However, the ability to save changes in Request Type was reserved for AXLR8 consultants. The reason was the cost to us of fixing mistakes. With the power of this new Workflow automation we need to work with a few clients to take responsibility and shoulder the expense of any errors before handing back the ability to save changes. We also assume most client Super Users would wish to work over a Teams meeting screenshare with an AXLR8 support consultant when building these IR Automations. The reason is that mistakes can be costly to fix.

Audit Log

In the audit log view we can see the Cancelled status is a “Close” status, the save object has also set the “Date Closed” date (same as if you set the IR to cancelled in the IR details screen).

Why must we update Bank Holiday dates? Some information requests have a response deadline in Calendar Days, e.g. SARs. Others like FOI and EIR must be completed in Working days. These “Request Types” are configured in Request Type Admin.

The AXLR8 system must exclude weekends and public holidays for those Request Types. Request Types change from jurisdiction to jurisdiction and in some countries local areas may differ. So, AXLR8 have a simple solution. We provide a Bank Holiday Admin area where you can manage your organisation’s public holiday dates.

Bank Holiday Admin

The Bank Holiday Admin function is to be found in the Super User menu. It is down at the bottom. The reason is that it is not used very often. You can add a few years in ahead if you wish. Don’t forget a diary date to review them.

You can add (or remove) dates for public holidays. This is shown below.

These days are excluded from the day-count up to the response deadline.

Responsibility for updating Bank Holidays

You, the client, are responsible for keeping your Bank Holidays updated. We enter the pubic holidays for a year with you as part of the Super User Systems Admin training. This is done when we first implement your system.

Occasionally, we find a client who has forgotten to update them after that.

We sometimes ask clients if they would like one of our interns to help. It is a good “work experience” job. This might be whilst working on their system on another support job. In that case, we inform the client. Please do not rely upon it. Set a date in your diary. Once a year should do it. There are too many clients and local variations for AXLR8 to manage it centrally.

Sometimes the original Information Request Type must change. What happens to the Due Date?
The most obvious example is when you log an FOI request thinking it is simple and it turns out to be more complex. It might be that clarification by the applicant expands the scope or the department providing some or all of the expertise explains an unforseen depth and raises more questions than answers.

Example 1: FOI changes to FOI Extended

An FOI request allows you 20 working days to respond. Bank Holidays in your jurisdiction and weekends are excluded. If a request is complex or more time is required, you may be able to extend that response time to 40 working days. In some jurisdictions there may also be 60 day FOI periods.
You can start with an FOI request and realise at some point that it will not be as simple to respond as had originally been thought. Therefore, you can change it to an “FOI Extended” with 40 days to respond. The AXLR8 system will then take the days that have already run and recalculate the new due date and hence the days outstanding wil have 20 days added on.

Let us take a simple example. FOI Request 1234 comes in and is set as an FOI 20 request type. The code indicates that it is and FOI request and has 20 working dats to run. It comes in on 11/04/2025, the day I am writing this FAQ. The due date will become 14/05/2025. Please note I took this from Demoshire2 which is presently set to English Bank Holidays in 2025 ( April 18 & 21, May 5 & 26 and Aug 25th). Assume for now that no restart for Clarification was required.

Let’s say it runs for 5 working days. Now, there are 15 working days left. I decide it is a 40 day FOI request instead. Then the clock will keep the days already used but the due date will be calculated as if it had been a 40 day request in the first place. So, it will change the due date to 12/06/2025. and the countdown will change from 15 days left to 35 days left. You can see why the public holidays were mentioned above!

Example 2: FOI changes to DPA Access then to DPA Access Extended

This was a real query from a client.

“We also have a query about request types changing throughout the request life, and how this changes the due date on requests (e.g. if a request is first thought to be FOISA , then changed to DPA – Access request and then changed to DPA – Access complex).“

We can use this as an example and apply the principles above. Same public holidays for simplicity even though this actually came from a different jurisdiction – Scotland whose bank holidays are different as yours may be. We have applied the rule that a response last day for a DPA/SAR may not fall on a weekend or bank holiday.

NB Please assume that any clarification or proof of ID has taken place beforehand. If it had not, the system would deal with those legitimate delays. It recalculates the Due Date as events take place.

AXLR8 are enhancing the system to work with calendar months. Choosing 28 days is accepted by most jurisdictions ( e.g. OIC). However, our feedback is that clients would prefer precise calendar months. This means that an IG team can complete a request in a 31 day month in 29 or 30 days. KPI reports will not show it as late. This new development is expected soon.

Example 3: May 25th 2018 – introduction of GDPR

The rules all changed for GDPR. AXLR8 just made the SAR requests starting on that Friday morning of the 25th run for a month. This is still the rule. Previously you were allowed 40 calendar days.

Every DPA request logged before midnight on 24th ran through to the end of its 40 day pre-GDPR processing time. So, AXLR8 made this enormous transition without any adverse results or extra charges.

Additional extended periods for more demanding SARS could also be chosen after that time.

Audit Trail

NB the changes made will be in the audit trail and so there is a visible “journey”. You can track how and when, the Coundown and Due Date has changed. It also shows which user made those changes.

KPIs

The Reports will accurately present the statistics. For example, it will show those responses which were late or on time and by how many days.

Questions?

You may have other examples and wish to play them through our system to check them.

Please do not hestiate to ask.

Short answer, anything you want during any timescale you can afford.

However, this is a standard AXLR8 demo of 48 minutes plus questions.

Items such as migration from legacy systems and security and other areas of compliance required in the public sector will be dealt with in depth if required at a later stage.

Other tools

If of interest, we can always look at other IG tools later Data Breach, DPIA, Information Asset Register, Data Sharing Policy Register, etc.  Also, Complaints Processing and other workflows.

AXLR8 configure Information Request Types for you. We make sure they have the correct “clock” settings, privacy flags and auto-deletion parameters for your Retention Policy. We have templates ready for most jurisdictions.

Here are three examples from our Demo system. Please also see Request Status which works with Request Types to enable events (e.g. “clarification” or “quotation” or “checking proof of ID” or closure) to stop, pause or reset the “clock” as appropriate.

FOI Request Type

The clock is set to ignore bank holidays. Privacy is not flagged (although, see below for “Sensitive FOI”)

Extended FOI

For those FOI requests that require more time – say 40 days, you can create a variant of the FOI Request Type. The only difference is that it has a 40 day “clock”. If you change from and FOI to an FOI – Extended, the deadline will automatically change. Thus, for example, if you realise, on day 9, that an FOI will be much more work, then you have 11 working days to go. If you simply change the Request Type in the drop down box, then you will automatically see the deadline date change to 31 working days hence. The set up ALR8 apply to this is shown below. Some clients have also asked us for other extensions on Request Types.

SAR Request Type

The clock runs including weekends and bank/public holidays. I.e. it works on Calendar days. It is also “Private“.

Sensitive FOI

This is a Request Type for FOIs that include personal, private content. The clock can still run as an FOI but the “Private” flag is set both internally and externally. The “Public” flag is not set. Some organisations ask AXLR8 to set the DPA flag and treat them fully as if they were SARs. They may be Sensitive FOIs for other reasons.

How configuring a Request Type changes IR lifecycle

How else to these parameters change the way the AXLR8 system manages IRs?

1. Length of time to deadline for response progress tracking
2. Appearance or not on the Public Disclosure Log
3. Colours to distinguish them on reports built with AXLR8 Report Builder
4. Privacy settings for users (most of whom will not see “private” flagged request types.
5. Working days (exclude weekends and public holidays set by your organisation in Bank Holiday Admin) or Calendar days.
6. Whether it is in DPA or FOI or EIR reports and screens
7. How retention automation works
8. …………………..and many more.

It is critical to get the Request Types configured correctly. You can see the implications from the list above. We need to consider every dependency.

If you need any changes to your request types, please contact AXLR8 Support. We will be happy to help. You can read the Request Type Admin area but not make any changes yourself. Your AXLR8 Support consultant will ask you for details and configure and test it across business rules with a programmer.

Information Request Workflow Automation was introduced here as a way to improve productivity for public sector IG Teams. Some Use cases are listed. We show how one of them might be automated and how the User Permissions work to make sure only the correct people design and deploy the robots.

Proof of Identity Workflow Automation

The example below is a abridged schematic of SAR workflow. Obviously, there is much more to it and more detailed workflow charts can be found elsewhere on this site.

Automation steps

Typically, the process building this in to your AXLR8 IRMS starts with your requirements.

1. In Document Template Admin, build the messages for each stage in the medium desired.  Usually these will be emails, SMS Messages or Word documents. For example reminders using Trigaware™ after waiting for a PoID for a SAR.  The messaging can be simple or intelligent with personalisation and very specific conditional contents. (see smart messaging).
2. We set up a “custom event definition” (i.e. the point in your workflow at which you need the document to go to the client).
3. Define the Status Life Cycle: the next section describes how to define a time limit for a status and any status change that follows completion of that life cycle. The life (cycle) of a status is the time it runs for or period before it closes itself and kicks off the new status.

Stage 1 Messaging to match your status change requirement

These examples match the work flow above.

• Inform the applicant that the IG team need this from the applicant when the IR is set to “Clarification Requested”
• Then alert them that 20 days has passed and there are 20 days remaining before they will have to resubmit their request. This would happen when the Clarification Second Request auto launched itself.
• The IR will close when the 40 days end and there has been no Clarification (or PoID). A third Trigger email can be programmed to go out. It would inform the applicant that their IR is now closed. They will have to resubmit it if they still need the information.

Stage 2: Create Automated Information Request

The best way to accomplish your objectives for Information Request automations is to create new IR Statuses. The reason for this is that all existing IRs that are running with that status will suddenly automate. If that is OK with you, go for it. We will describe how you do that below but you should consider the safer route of creating and applying a new one.

Please refer to the screenshots below which show the update of an IR Status and the creation of a new one.
The existing IR Status called “SAR ID Requested” for this client could be upgraded by:

• adding the tick for Time limited Status
• adding a duration of 20 days
• selecting a carry on status (in this case it will “Final SAR Request”)
• ticking the box for Special User Access. (see “User Permissions” below)

So after 20 days from the initial request, the IR is automatically sent to the next status of a final 20 days where they are on notice that the IR will be closed after that period. This is a total of 40 days. Very reasonable if you automate some reminders for the applicant as well.

In the above example, we updated and existing IR Status for our first 20 day SAR Request for PoID. Below we have created a new Information Request Status, also 20 days in duration and the last 20 day period they have in which to prove they are who they say they are before work starts finding their requested information. In the green box, to confirm the process above, we did the same ticks and duration. The difference is that the end of the 20 days automatically changes the status to Cancelled by Requester. Again, your organisation may have different vocabulary. You might call that “Failed to supply PoID” or some other label. In any case, it would close the IR because this final status would be a “finished” status.

So, we now have a “chain” of three actions that will hand over like a relay race with no human intervention necessary until PoID is received and agreed as valid, one day. Then the automated process is stopped and work begins with that request.

NB in the above example, you will see that this IR Status is disabled (tick box at the top). That is because We have not yet applied user permissions (or tested it).

Note. It is best not to apply the time limited status settings to existing IR statuses unless you are confident you know the outcome.  The next time it runs, it would run on all the existing IR records that have that existing status. Do you want that?  If you do make a status time limited, it would be best to search to see how many IR’s have that status, and understand that if they were given it more than the duration number of “valid” days ago, that “it will” change the status next time it runs.

Stage 3. Review User Permissions

Not all users should have the authority or expertise to apply a timed status. They may launch a wrong workflow automation. For example, without knowing the next steps, they could create an infinite loop. Users need to have the new user permission to apply one of these time limited statuses when they are first created. Later, when ta few runs through have proven the automations, you can remove the restriction from the IR status. This is done by removing the “Special User Access” shown in the screenshots in the previous stage. Below is how we can set up a knowledgeable pilot user to be able to use the new timed IR Statuses.

There is a new User Permission. It is called “Can apply Special User Access Statuses”, on user admin. Here is an example from a real client showing where it is on the User Admin screen.

If a User tries to apply a Time Limited IR Status to an Information Request, they may not be able to do so. If they do not have permission, they will get the following message.

For someone with this permission, the above alert message (example from City of Edinburgh) will not appear. That User can save their chosen status.

Systems Admin Permissions

As described above, your Super Users may decide which Users may apply these IR Statuses with timings built in. I.e. the “special User Access” IR statuses.

We have disabled update rights for clients but you have complete visibility of information Request Statuses. You can request an AXLR8 consultant to make the change.  Thus in your office, similar to the Dropdowns admin for Request Type, the Dropdowns Admin for Information Request Status only has a Save function when one of our consultants is using it. 
It is not available from client offices. AXLR8 have retained some of the administrative privileges for our support specialists for Request Status Admin.

The “Save” function in Information Request Status “Dropdowns Admin” was always available for Super Users at our clients. However, the ability to save changes in Request Type was reserved for AXLR8 consultants. The reason was the cost to us of fixing mistakes. With the power of this new Workflow automation we need to work with a few clients to take responsibility and shoulder the expense of any errors before handing back the ability to save changes. We also assume most client Super Users would wish to work over a Teams meeting screenshare with an AXLR8 support consultant when building these IR Automations. The reason is that mistakes can be costly to fix.

Audit Log

In the audit log view we can see the Cancelled status is a “Close” status, the save object has also set the “Date Closed” date (same as if you set the IR to cancelled in the IR details screen).

Messagestore takes a copy of all relevant email messages that enter and leave your business. For example, you might be set up to take any email to or from foi@yourorganisation.gov.uk and dataprotection@yourorganisation.gov.uk.

Messagestore then files them against the recipients and senders and the information request unique identifiers. The unique identifiers are coded into the subject lines in the email templates and the numbers and short descriptions are mail merged in.

This is described in greater detail together with “use cases”, blogs and articles on the messagestore.co.uk specialist website.

Merging IR references into the email subject line

The subject line of emails can have mailmerged data in them in the same way as you mail merge data into the body of a document.

The mailmerge templates are created and maintained in Document Template Admin.

Messagestore and Email2IR

Messagestore provides the platform for AXLR8’s Email2IR functionality. Email2IR checks Messagestore for any incoming email and creates a new IR ready for human management decisions:

1. request type (or you can clik the “Spam” button) and
2. the applicant (add new or allocate to a previous “frequent flier”).

If there is an exisiting IR reference in the subject line of the incoming email, then that incoming email does not create a new IR. The process checks for whether the email is about an exisiting IRs. It accomplishes this by reading the subject line. If there is and IR code in it, then it will add it to the “job bag” for that IR.

Please call if you need any training on this area or have any concerns about controlling visibility of emails for different groups of users.

Sometimes the original Information Request Type must change. What happens to the Due Date?
The most obvious example is when you log an FOI request thinking it is simple and it turns out to be more complex. It might be that clarification by the applicant expands the scope or the department providing some or all of the expertise explains an unforseen depth and raises more questions than answers.

Example 1: FOI changes to FOI Extended

An FOI request allows you 20 working days to respond. Bank Holidays in your jurisdiction and weekends are excluded. If a request is complex or more time is required, you may be able to extend that response time to 40 working days. In some jurisdictions there may also be 60 day FOI periods.
You can start with an FOI request and realise at some point that it will not be as simple to respond as had originally been thought. Therefore, you can change it to an “FOI Extended” with 40 days to respond. The AXLR8 system will then take the days that have already run and recalculate the new due date and hence the days outstanding wil have 20 days added on.

Let us take a simple example. FOI Request 1234 comes in and is set as an FOI 20 request type. The code indicates that it is and FOI request and has 20 working dats to run. It comes in on 11/04/2025, the day I am writing this FAQ. The due date will become 14/05/2025. Please note I took this from Demoshire2 which is presently set to English Bank Holidays in 2025 ( April 18 & 21, May 5 & 26 and Aug 25th). Assume for now that no restart for Clarification was required.

Let’s say it runs for 5 working days. Now, there are 15 working days left. I decide it is a 40 day FOI request instead. Then the clock will keep the days already used but the due date will be calculated as if it had been a 40 day request in the first place. So, it will change the due date to 12/06/2025. and the countdown will change from 15 days left to 35 days left. You can see why the public holidays were mentioned above!

Example 2: FOI changes to DPA Access then to DPA Access Extended

This was a real query from a client.

“We also have a query about request types changing throughout the request life, and how this changes the due date on requests (e.g. if a request is first thought to be FOISA , then changed to DPA – Access request and then changed to DPA – Access complex).“

We can use this as an example and apply the principles above. Same public holidays for simplicity even though this actually came from a different jurisdiction – Scotland whose bank holidays are different as yours may be. We have applied the rule that a response last day for a DPA/SAR may not fall on a weekend or bank holiday.

NB Please assume that any clarification or proof of ID has taken place beforehand. If it had not, the system would deal with those legitimate delays. It recalculates the Due Date as events take place.

AXLR8 are enhancing the system to work with calendar months. Choosing 28 days is accepted by most jurisdictions ( e.g. OIC). However, our feedback is that clients would prefer precise calendar months. This means that an IG team can complete a request in a 31 day month in 29 or 30 days. KPI reports will not show it as late. This new development is expected soon.

Example 3: May 25th 2018 – introduction of GDPR

The rules all changed for GDPR. AXLR8 just made the SAR requests starting on that Friday morning of the 25th run for a month. This is still the rule. Previously you were allowed 40 calendar days.

Every DPA request logged before midnight on 24th ran through to the end of its 40 day pre-GDPR processing time. So, AXLR8 made this enormous transition without any adverse results or extra charges.

Additional extended periods for more demanding SARS could also be chosen after that time.

Audit Trail

NB the changes made will be in the audit trail and so there is a visible “journey”. You can track how and when, the Coundown and Due Date has changed. It also shows which user made those changes.

KPIs

The Reports will accurately present the statistics. For example, it will show those responses which were late or on time and by how many days.

Questions?

You may have other examples and wish to play them through our system to check them.

Please do not hestiate to ask.

Short answer, anything you want during any timescale you can afford.

However, this is a standard AXLR8 demo of 48 minutes plus questions.

Items such as migration from legacy systems and security and other areas of compliance required in the public sector will be dealt with in depth if required at a later stage.

Other tools

If of interest, we can always look at other IG tools later Data Breach, DPIA, Information Asset Register, Data Sharing Policy Register, etc.  Also, Complaints Processing and other workflows.

AXLR8 configure Information Request Types for you. We make sure they have the correct “clock” settings, privacy flags and auto-deletion parameters for your Retention Policy. We have templates ready for most jurisdictions.

Here are three examples from our Demo system. Please also see Request Status which works with Request Types to enable events (e.g. “clarification” or “quotation” or “checking proof of ID” or closure) to stop, pause or reset the “clock” as appropriate.

FOI Request Type

The clock is set to ignore bank holidays. Privacy is not flagged (although, see below for “Sensitive FOI”)

Extended FOI

For those FOI requests that require more time – say 40 days, you can create a variant of the FOI Request Type. The only difference is that it has a 40 day “clock”. If you change from and FOI to an FOI – Extended, the deadline will automatically change. Thus, for example, if you realise, on day 9, that an FOI will be much more work, then you have 11 working days to go. If you simply change the Request Type in the drop down box, then you will automatically see the deadline date change to 31 working days hence. The set up ALR8 apply to this is shown below. Some clients have also asked us for other extensions on Request Types.

SAR Request Type

The clock runs including weekends and bank/public holidays. I.e. it works on Calendar days. It is also “Private“.

Sensitive FOI

This is a Request Type for FOIs that include personal, private content. The clock can still run as an FOI but the “Private” flag is set both internally and externally. The “Public” flag is not set. Some organisations ask AXLR8 to set the DPA flag and treat them fully as if they were SARs. They may be Sensitive FOIs for other reasons.

How configuring a Request Type changes IR lifecycle

How else to these parameters change the way the AXLR8 system manages IRs?

1. Length of time to deadline for response progress tracking
2. Appearance or not on the Public Disclosure Log
3. Colours to distinguish them on reports built with AXLR8 Report Builder
4. Privacy settings for users (most of whom will not see “private” flagged request types.
5. Working days (exclude weekends and public holidays set by your organisation in Bank Holiday Admin) or Calendar days.
6. Whether it is in DPA or FOI or EIR reports and screens
7. How retention automation works
8. …………………..and many more.

It is critical to get the Request Types configured correctly. You can see the implications from the list above. We need to consider every dependency.

If you need any changes to your request types, please contact AXLR8 Support. We will be happy to help. You can read the Request Type Admin area but not make any changes yourself. Your AXLR8 Support consultant will ask you for details and configure and test it across business rules with a programmer.

Information Request Workflow Automation was introduced here as a way to improve productivity for public sector IG Teams. Some Use cases are listed. We show how one of them might be automated and how the User Permissions work to make sure only the correct people design and deploy the robots.

Proof of Identity Workflow Automation

The example below is a abridged schematic of SAR workflow. Obviously, there is much more to it and more detailed workflow charts can be found elsewhere on this site.

Automation steps

Typically, the process building this in to your AXLR8 IRMS starts with your requirements.

1. In Document Template Admin, build the messages for each stage in the medium desired.  Usually these will be emails, SMS Messages or Word documents. For example reminders using Trigaware™ after waiting for a PoID for a SAR.  The messaging can be simple or intelligent with personalisation and very specific conditional contents. (see smart messaging).
2. We set up a “custom event definition” (i.e. the point in your workflow at which you need the document to go to the client).
3. Define the Status Life Cycle: the next section describes how to define a time limit for a status and any status change that follows completion of that life cycle. The life (cycle) of a status is the time it runs for or period before it closes itself and kicks off the new status.

Stage 1 Messaging to match your status change requirement

These examples match the work flow above.

• Inform the applicant that the IG team need this from the applicant when the IR is set to “Clarification Requested”
• Then alert them that 20 days has passed and there are 20 days remaining before they will have to resubmit their request. This would happen when the Clarification Second Request auto launched itself.
• The IR will close when the 40 days end and there has been no Clarification (or PoID). A third Trigger email can be programmed to go out. It would inform the applicant that their IR is now closed. They will have to resubmit it if they still need the information.

Stage 2: Create Automated Information Request

The best way to accomplish your objectives for Information Request automations is to create new IR Statuses. The reason for this is that all existing IRs that are running with that status will suddenly automate. If that is OK with you, go for it. We will describe how you do that below but you should consider the safer route of creating and applying a new one.

Please refer to the screenshots below which show the update of an IR Status and the creation of a new one.
The existing IR Status called “SAR ID Requested” for this client could be upgraded by:

• adding the tick for Time limited Status
• adding a duration of 20 days
• selecting a carry on status (in this case it will “Final SAR Request”)
• ticking the box for Special User Access. (see “User Permissions” below)

So after 20 days from the initial request, the IR is automatically sent to the next status of a final 20 days where they are on notice that the IR will be closed after that period. This is a total of 40 days. Very reasonable if you automate some reminders for the applicant as well.

In the above example, we updated and existing IR Status for our first 20 day SAR Request for PoID. Below we have created a new Information Request Status, also 20 days in duration and the last 20 day period they have in which to prove they are who they say they are before work starts finding their requested information. In the green box, to confirm the process above, we did the same ticks and duration. The difference is that the end of the 20 days automatically changes the status to Cancelled by Requester. Again, your organisation may have different vocabulary. You might call that “Failed to supply PoID” or some other label. In any case, it would close the IR because this final status would be a “finished” status.

So, we now have a “chain” of three actions that will hand over like a relay race with no human intervention necessary until PoID is received and agreed as valid, one day. Then the automated process is stopped and work begins with that request.

NB in the above example, you will see that this IR Status is disabled (tick box at the top). That is because We have not yet applied user permissions (or tested it).

Note. It is best not to apply the time limited status settings to existing IR statuses unless you are confident you know the outcome.  The next time it runs, it would run on all the existing IR records that have that existing status. Do you want that?  If you do make a status time limited, it would be best to search to see how many IR’s have that status, and understand that if they were given it more than the duration number of “valid” days ago, that “it will” change the status next time it runs.

Stage 3. Review User Permissions

Not all users should have the authority or expertise to apply a timed status. They may launch a wrong workflow automation. For example, without knowing the next steps, they could create an infinite loop. Users need to have the new user permission to apply one of these time limited statuses when they are first created. Later, when ta few runs through have proven the automations, you can remove the restriction from the IR status. This is done by removing the “Special User Access” shown in the screenshots in the previous stage. Below is how we can set up a knowledgeable pilot user to be able to use the new timed IR Statuses.

There is a new User Permission. It is called “Can apply Special User Access Statuses”, on user admin. Here is an example from a real client showing where it is on the User Admin screen.

If a User tries to apply a Time Limited IR Status to an Information Request, they may not be able to do so. If they do not have permission, they will get the following message.

For someone with this permission, the above alert message (example from City of Edinburgh) will not appear. That User can save their chosen status.

Systems Admin Permissions

As described above, your Super Users may decide which Users may apply these IR Statuses with timings built in. I.e. the “special User Access” IR statuses.

We have disabled update rights for clients but you have complete visibility of information Request Statuses. You can request an AXLR8 consultant to make the change.  Thus in your office, similar to the Dropdowns admin for Request Type, the Dropdowns Admin for Information Request Status only has a Save function when one of our consultants is using it. 
It is not available from client offices. AXLR8 have retained some of the administrative privileges for our support specialists for Request Status Admin.

The “Save” function in Information Request Status “Dropdowns Admin” was always available for Super Users at our clients. However, the ability to save changes in Request Type was reserved for AXLR8 consultants. The reason was the cost to us of fixing mistakes. With the power of this new Workflow automation we need to work with a few clients to take responsibility and shoulder the expense of any errors before handing back the ability to save changes. We also assume most client Super Users would wish to work over a Teams meeting screenshare with an AXLR8 support consultant when building these IR Automations. The reason is that mistakes can be costly to fix.

Audit Log

In the audit log view we can see the Cancelled status is a “Close” status, the save object has also set the “Date Closed” date (same as if you set the IR to cancelled in the IR details screen).

Sometimes the original Information Request Type must change. What happens to the Due Date?
The most obvious example is when you log an FOI request thinking it is simple and it turns out to be more complex. It might be that clarification by the applicant expands the scope or the department providing some or all of the expertise explains an unforseen depth and raises more questions than answers.

Example 1: FOI changes to FOI Extended

An FOI request allows you 20 working days to respond. Bank Holidays in your jurisdiction and weekends are excluded. If a request is complex or more time is required, you may be able to extend that response time to 40 working days. In some jurisdictions there may also be 60 day FOI periods.
You can start with an FOI request and realise at some point that it will not be as simple to respond as had originally been thought. Therefore, you can change it to an “FOI Extended” with 40 days to respond. The AXLR8 system will then take the days that have already run and recalculate the new due date and hence the days outstanding wil have 20 days added on.

Let us take a simple example. FOI Request 1234 comes in and is set as an FOI 20 request type. The code indicates that it is and FOI request and has 20 working dats to run. It comes in on 11/04/2025, the day I am writing this FAQ. The due date will become 14/05/2025. Please note I took this from Demoshire2 which is presently set to English Bank Holidays in 2025 ( April 18 & 21, May 5 & 26 and Aug 25th). Assume for now that no restart for Clarification was required.

Let’s say it runs for 5 working days. Now, there are 15 working days left. I decide it is a 40 day FOI request instead. Then the clock will keep the days already used but the due date will be calculated as if it had been a 40 day request in the first place. So, it will change the due date to 12/06/2025. and the countdown will change from 15 days left to 35 days left. You can see why the public holidays were mentioned above!

Example 2: FOI changes to DPA Access then to DPA Access Extended

This was a real query from a client.

“We also have a query about request types changing throughout the request life, and how this changes the due date on requests (e.g. if a request is first thought to be FOISA , then changed to DPA – Access request and then changed to DPA – Access complex).“

We can use this as an example and apply the principles above. Same public holidays for simplicity even though this actually came from a different jurisdiction – Scotland whose bank holidays are different as yours may be. We have applied the rule that a response last day for a DPA/SAR may not fall on a weekend or bank holiday.

NB Please assume that any clarification or proof of ID has taken place beforehand. If it had not, the system would deal with those legitimate delays. It recalculates the Due Date as events take place.

AXLR8 are enhancing the system to work with calendar months. Choosing 28 days is accepted by most jurisdictions ( e.g. OIC). However, our feedback is that clients would prefer precise calendar months. This means that an IG team can complete a request in a 31 day month in 29 or 30 days. KPI reports will not show it as late. This new development is expected soon.

Example 3: May 25th 2018 – introduction of GDPR

The rules all changed for GDPR. AXLR8 just made the SAR requests starting on that Friday morning of the 25th run for a month. This is still the rule. Previously you were allowed 40 calendar days.

Every DPA request logged before midnight on 24th ran through to the end of its 40 day pre-GDPR processing time. So, AXLR8 made this enormous transition without any adverse results or extra charges.

Additional extended periods for more demanding SARS could also be chosen after that time.

Audit Trail

NB the changes made will be in the audit trail and so there is a visible “journey”. You can track how and when, the Coundown and Due Date has changed. It also shows which user made those changes.

KPIs

The Reports will accurately present the statistics. For example, it will show those responses which were late or on time and by how many days.

Questions?

You may have other examples and wish to play them through our system to check them.

Please do not hestiate to ask.

Short answer, anything you want during any timescale you can afford.

However, this is a standard AXLR8 demo of 48 minutes plus questions.

Items such as migration from legacy systems and security and other areas of compliance required in the public sector will be dealt with in depth if required at a later stage.

Other tools

If of interest, we can always look at other IG tools later Data Breach, DPIA, Information Asset Register, Data Sharing Policy Register, etc.  Also, Complaints Processing and other workflows.

This is accomplished in Document Template Admin.
To find Document Template Admin, please select Admin menu (cog on LHS menu in the old system or Super User menu in the new UX). Then select Document Template Admin.
There you will see a list of documents already available.

Medium

• Letter
• Email
• Text (SMS) Message
• Other

File Types

The format of the email will allow it to present and send in diferent ways.

• .RTF that can be opened by a wide variety of document readers including MS Word
• .HTML for formatted emails with colours and different highlights, fonts, embedded hyperlinks
• .TXT for plain text emails
• other

Context

A mailing template may be built to work in various different contexts.

• Contact person only (name address, etc.)
  • Reviews and appeals
• Information Request where the dates (including due date), short descriptions, subject, exemptions, department, owners and applicants and much more information may be merged in specific to that IR.
• Activity (task within an activity with a specific owner or team to respond in a department
• Breach

Subject Line

The subject line determines ti a significan extent whether an email will be opened. You can mail merge fields of data into the subject line of your email template.

The scope for automation of tasks is enormous with smart mail merged correspondence available in a couple of clicks.

The documents created are also auto-attached to the Information Request. If you have AXLR8 Messagestore then incoming and outgoing emails will be stored against the Information Request, too.

Trigaware

There are also fully automated emails. These are in addition to the mail merged documents. They are launched by the AXLR8 Trigaware system which are preprogrammed on events. Examples include:

• auto acknowledgement to applicants including details of their request and the due date
• alert to the team handling responses
• reminders at 10 and 5 days before the due date for those esponsible
• alert when a department officer has added a File or Note to an Information Request.

Some clients have a two dozen of these set up containing alerts that change with conditions.

Trigaware auto emails are explained at length elsewhere.

Why must we update Bank Holiday dates? Some information requests have a response deadline in Calendar Days, e.g. SARs. Others like FOI and EIR must be completed in Working days. These “Request Types” are configured in Request Type Admin.

The AXLR8 system must exclude weekends and public holidays for those Request Types. Request Types change from jurisdiction to jurisdiction and in some countries local areas may differ. So, AXLR8 have a simple solution. We provide a Bank Holiday Admin area where you can manage your organisation’s public holiday dates.

Bank Holiday Admin

The Bank Holiday Admin function is to be found in the Super User menu. It is down at the bottom. The reason is that it is not used very often. You can add a few years in ahead if you wish. Don’t forget a diary date to review them.

You can add (or remove) dates for public holidays. This is shown below.

These days are excluded from the day-count up to the response deadline.

Responsibility for updating Bank Holidays

You, the client, are responsible for keeping your Bank Holidays updated. We enter the pubic holidays for a year with you as part of the Super User Systems Admin training. This is done when we first implement your system.

Occasionally, we find a client who has forgotten to update them after that.

We sometimes ask clients if they would like one of our interns to help. It is a good “work experience” job. This might be whilst working on their system on another support job. In that case, we inform the client. Please do not rely upon it. Set a date in your diary. Once a year should do it. There are too many clients and local variations for AXLR8 to manage it centrally.

Short answer, anything you want during any timescale you can afford.

However, this is a standard AXLR8 demo of 48 minutes plus questions.

Items such as migration from legacy systems and security and other areas of compliance required in the public sector will be dealt with in depth if required at a later stage.

Other tools

If of interest, we can always look at other IG tools later Data Breach, DPIA, Information Asset Register, Data Sharing Policy Register, etc.  Also, Complaints Processing and other workflows.

Just click here.

It evolves and we are happy to receive additions and corrections at AXLR8!

Information Request Workflow Automation was introduced here as a way to improve productivity for public sector IG Teams. Some Use cases are listed. We show how one of them might be automated and how the User Permissions work to make sure only the correct people design and deploy the robots.

Proof of Identity Workflow Automation

The example below is a abridged schematic of SAR workflow. Obviously, there is much more to it and more detailed workflow charts can be found elsewhere on this site.

Automation steps

Typically, the process building this in to your AXLR8 IRMS starts with your requirements.

1. In Document Template Admin, build the messages for each stage in the medium desired.  Usually these will be emails, SMS Messages or Word documents. For example reminders using Trigaware™ after waiting for a PoID for a SAR.  The messaging can be simple or intelligent with personalisation and very specific conditional contents. (see smart messaging).
2. We set up a “custom event definition” (i.e. the point in your workflow at which you need the document to go to the client).
3. Define the Status Life Cycle: the next section describes how to define a time limit for a status and any status change that follows completion of that life cycle. The life (cycle) of a status is the time it runs for or period before it closes itself and kicks off the new status.

Stage 1 Messaging to match your status change requirement

These examples match the work flow above.

• Inform the applicant that the IG team need this from the applicant when the IR is set to “Clarification Requested”
• Then alert them that 20 days has passed and there are 20 days remaining before they will have to resubmit their request. This would happen when the Clarification Second Request auto launched itself.
• The IR will close when the 40 days end and there has been no Clarification (or PoID). A third Trigger email can be programmed to go out. It would inform the applicant that their IR is now closed. They will have to resubmit it if they still need the information.

Stage 2: Create Automated Information Request

The best way to accomplish your objectives for Information Request automations is to create new IR Statuses. The reason for this is that all existing IRs that are running with that status will suddenly automate. If that is OK with you, go for it. We will describe how you do that below but you should consider the safer route of creating and applying a new one.

Please refer to the screenshots below which show the update of an IR Status and the creation of a new one.
The existing IR Status called “SAR ID Requested” for this client could be upgraded by:

• adding the tick for Time limited Status
• adding a duration of 20 days
• selecting a carry on status (in this case it will “Final SAR Request”)
• ticking the box for Special User Access. (see “User Permissions” below)

So after 20 days from the initial request, the IR is automatically sent to the next status of a final 20 days where they are on notice that the IR will be closed after that period. This is a total of 40 days. Very reasonable if you automate some reminders for the applicant as well.

In the above example, we updated and existing IR Status for our first 20 day SAR Request for PoID. Below we have created a new Information Request Status, also 20 days in duration and the last 20 day period they have in which to prove they are who they say they are before work starts finding their requested information. In the green box, to confirm the process above, we did the same ticks and duration. The difference is that the end of the 20 days automatically changes the status to Cancelled by Requester. Again, your organisation may have different vocabulary. You might call that “Failed to supply PoID” or some other label. In any case, it would close the IR because this final status would be a “finished” status.

So, we now have a “chain” of three actions that will hand over like a relay race with no human intervention necessary until PoID is received and agreed as valid, one day. Then the automated process is stopped and work begins with that request.

NB in the above example, you will see that this IR Status is disabled (tick box at the top). That is because We have not yet applied user permissions (or tested it).

Note. It is best not to apply the time limited status settings to existing IR statuses unless you are confident you know the outcome.  The next time it runs, it would run on all the existing IR records that have that existing status. Do you want that?  If you do make a status time limited, it would be best to search to see how many IR’s have that status, and understand that if they were given it more than the duration number of “valid” days ago, that “it will” change the status next time it runs.

Stage 3. Review User Permissions

Not all users should have the authority or expertise to apply a timed status. They may launch a wrong workflow automation. For example, without knowing the next steps, they could create an infinite loop. Users need to have the new user permission to apply one of these time limited statuses when they are first created. Later, when ta few runs through have proven the automations, you can remove the restriction from the IR status. This is done by removing the “Special User Access” shown in the screenshots in the previous stage. Below is how we can set up a knowledgeable pilot user to be able to use the new timed IR Statuses.

There is a new User Permission. It is called “Can apply Special User Access Statuses”, on user admin. Here is an example from a real client showing where it is on the User Admin screen.

If a User tries to apply a Time Limited IR Status to an Information Request, they may not be able to do so. If they do not have permission, they will get the following message.

For someone with this permission, the above alert message (example from City of Edinburgh) will not appear. That User can save their chosen status.

Systems Admin Permissions

As described above, your Super Users may decide which Users may apply these IR Statuses with timings built in. I.e. the “special User Access” IR statuses.

We have disabled update rights for clients but you have complete visibility of information Request Statuses. You can request an AXLR8 consultant to make the change.  Thus in your office, similar to the Dropdowns admin for Request Type, the Dropdowns Admin for Information Request Status only has a Save function when one of our consultants is using it. 
It is not available from client offices. AXLR8 have retained some of the administrative privileges for our support specialists for Request Status Admin.

The “Save” function in Information Request Status “Dropdowns Admin” was always available for Super Users at our clients. However, the ability to save changes in Request Type was reserved for AXLR8 consultants. The reason was the cost to us of fixing mistakes. With the power of this new Workflow automation we need to work with a few clients to take responsibility and shoulder the expense of any errors before handing back the ability to save changes. We also assume most client Super Users would wish to work over a Teams meeting screenshare with an AXLR8 support consultant when building these IR Automations. The reason is that mistakes can be costly to fix.

Audit Log

In the audit log view we can see the Cancelled status is a “Close” status, the save object has also set the “Date Closed” date (same as if you set the IR to cancelled in the IR details screen).

There are several approaches you can take. Here are the three most popular.

Make it a Sensitive FOI

This is an FOI request that requires personal data in the answer which you feel should be protected as if it were a SAR.

A question about several streets might be FOI but a question a bout a specific house identifies a resident and may thus include PII.

Let’s say there are 5 parts to a question which is about compensation of nurses. Part 3 asks you about the applicant’s specific compensation but the rest are about general rules and amounts over the last couple of years.

In both examples one may chjoose to use a “Sensitive FOI”. That request type should be configured as “Private” and hence it will not

1. appear in the PDL (Public Disclosure Log)
2. be visible to staff with out access to Private Request Types

Make it a SAR

It may be that the request is so peculiar to a person that it is really a SAR. This happens occasionally and is a natural solution which immediately covers you for any possibility that the data will be published outside your organisation. It will also not be seen by those without “Private” Request Type access.

Make two IRs: a SAR and and EIR

There may be a number of questions in the IR and you can create two IRs. Let us take the above example with 5 parts. Part 3 could be a SAR and parts 1,2,4&5 could be sent out in a second IR which was classified as an FOI request.

Which to choose?

Obviously, the first is the simplest. The advantages of a “sensitive” FOI (FOISA, EIR, etc.) are that they are excluded from the Public Disclosure Log and are not seen by any staff whose access excludes Private request types.

The automated emails will have been set up so that they do not expose PII in the wrong places. Policies and workflow procedures would need to be in place so that the information management team know to make the subject line “Bill Smith’s Compensation” (in the above example). Rather they might make the correspondence subject “Potholes Compensation”.

The only other thing to consider is triage speed. Once you have set an IR as FOI, some automated triggers may have been launched. That needs to be taken into account before changing the request to a Sensitive FOI or SAR after a week of activity. Occasionally, however, it is not obvious for an officer at first. Senior staff are not present and a mistake is made.

What if I change IR Types during a response period?

There is a related article about what happens to the Countdown and Due Date when you change and IR Type from FOI to SAR.

What are Private Request Types?

Generally, these Requests would be SARs, Sensitive FOIs and some that are specific to different jurisdictions. Examples include: CAFCAS in UK and Procurator Fiscal in Scotland.

Please see the FAQ article about configuring Request Types. It explains how their behaviour differs in the AXLR8 system.

Generally these would be SARs, Sensitive FOIs and some that are specific to different jurisdictions. Examples include: CAFCAS in UK and Procurator Fiscal in Scotland.

The Request Types in the AXLR8 system are completely customisable for any jurisdiction (or just because your organisation needs to). This means setting it up with the “Private” parameter set to “Yes”. It may also be that there are Request Types that are not private but may not be shown on the Public Disclosure Log. That can be set separately as you can see in the orange box below.

How does the AXLR8 system treat Private Request Types?

1. Only those with Private IR access may see them. This is different to the Application Blind parameter in User Admin which prevents a user seeing any applicant details, regardless of the type of request.
2. The automated emails can be set up differently. For example, the Subject line of email correspondence and file names of documents may say the Request Type and the unique reference number. For example the subject line might say “SAR- ACCESS demoshireIR:12345” but not the name of the applicant for who you are collecting the information. Compare this with the subject line for an FOI request which would say “Potholes vehicle damage compensation FY2023-4 DemoshireIR:12346“.
3. The Request will not show on the PDL (Public Disclosure Log) for your organisation.

Response Times

The response times are unaffected by the “Private” flag shown above. How these timings work as well as how they change with clarifications and proof of identity and other events is described elsewhere.

The time for completion is set elsewhere. A Sensitive FOI (assuming not extended) still runs to a deadline of 20 working days. A SAR still has a month regardless of bank holidays and weekends.

Short answer, anything you want during any timescale you can afford.

However, this is a standard AXLR8 demo of 48 minutes plus questions.

Items such as migration from legacy systems and security and other areas of compliance required in the public sector will be dealt with in depth if required at a later stage.

Other tools

If of interest, we can always look at other IG tools later Data Breach, DPIA, Information Asset Register, Data Sharing Policy Register, etc.  Also, Complaints Processing and other workflows.

AXLR8 configure Information Request Types for you. We make sure they have the correct “clock” settings, privacy flags and auto-deletion parameters for your Retention Policy. We have templates ready for most jurisdictions.

Here are three examples from our Demo system. Please also see Request Status which works with Request Types to enable events (e.g. “clarification” or “quotation” or “checking proof of ID” or closure) to stop, pause or reset the “clock” as appropriate.

FOI Request Type

The clock is set to ignore bank holidays. Privacy is not flagged (although, see below for “Sensitive FOI”)

Extended FOI

For those FOI requests that require more time – say 40 days, you can create a variant of the FOI Request Type. The only difference is that it has a 40 day “clock”. If you change from and FOI to an FOI – Extended, the deadline will automatically change. Thus, for example, if you realise, on day 9, that an FOI will be much more work, then you have 11 working days to go. If you simply change the Request Type in the drop down box, then you will automatically see the deadline date change to 31 working days hence. The set up ALR8 apply to this is shown below. Some clients have also asked us for other extensions on Request Types.

SAR Request Type

The clock runs including weekends and bank/public holidays. I.e. it works on Calendar days. It is also “Private“.

Sensitive FOI

This is a Request Type for FOIs that include personal, private content. The clock can still run as an FOI but the “Private” flag is set both internally and externally. The “Public” flag is not set. Some organisations ask AXLR8 to set the DPA flag and treat them fully as if they were SARs. They may be Sensitive FOIs for other reasons.

How configuring a Request Type changes IR lifecycle

How else to these parameters change the way the AXLR8 system manages IRs?

1. Length of time to deadline for response progress tracking
2. Appearance or not on the Public Disclosure Log
3. Colours to distinguish them on reports built with AXLR8 Report Builder
4. Privacy settings for users (most of whom will not see “private” flagged request types.
5. Working days (exclude weekends and public holidays set by your organisation in Bank Holiday Admin) or Calendar days.
6. Whether it is in DPA or FOI or EIR reports and screens
7. How retention automation works
8. …………………..and many more.

It is critical to get the Request Types configured correctly. You can see the implications from the list above. We need to consider every dependency.

If you need any changes to your request types, please contact AXLR8 Support. We will be happy to help. You can read the Request Type Admin area but not make any changes yourself. Your AXLR8 Support consultant will ask you for details and configure and test it across business rules with a programmer.

Why must we update Bank Holiday dates? Some information requests have a response deadline in Calendar Days, e.g. SARs. Others like FOI and EIR must be completed in Working days. These “Request Types” are configured in Request Type Admin.

The AXLR8 system must exclude weekends and public holidays for those Request Types. Request Types change from jurisdiction to jurisdiction and in some countries local areas may differ. So, AXLR8 have a simple solution. We provide a Bank Holiday Admin area where you can manage your organisation’s public holiday dates.

Bank Holiday Admin

The Bank Holiday Admin function is to be found in the Super User menu. It is down at the bottom. The reason is that it is not used very often. You can add a few years in ahead if you wish. Don’t forget a diary date to review them.

You can add (or remove) dates for public holidays. This is shown below.

These days are excluded from the day-count up to the response deadline.

Responsibility for updating Bank Holidays

You, the client, are responsible for keeping your Bank Holidays updated. We enter the pubic holidays for a year with you as part of the Super User Systems Admin training. This is done when we first implement your system.

Occasionally, we find a client who has forgotten to update them after that.

We sometimes ask clients if they would like one of our interns to help. It is a good “work experience” job. This might be whilst working on their system on another support job. In that case, we inform the client. Please do not rely upon it. Set a date in your diary. Once a year should do it. There are too many clients and local variations for AXLR8 to manage it centrally.

Short answer, anything you want during any timescale you can afford.

However, this is a standard AXLR8 demo of 48 minutes plus questions.

Items such as migration from legacy systems and security and other areas of compliance required in the public sector will be dealt with in depth if required at a later stage.

Other tools

If of interest, we can always look at other IG tools later Data Breach, DPIA, Information Asset Register, Data Sharing Policy Register, etc.  Also, Complaints Processing and other workflows.

This is accomplished in Document Template Admin.
To find Document Template Admin, please select Admin menu (cog on LHS menu in the old system or Super User menu in the new UX). Then select Document Template Admin.
There you will see a list of documents already available.

Medium

• Letter
• Email
• Text (SMS) Message
• Other

File Types

The format of the email will allow it to present and send in diferent ways.

• .RTF that can be opened by a wide variety of document readers including MS Word
• .HTML for formatted emails with colours and different highlights, fonts, embedded hyperlinks
• .TXT for plain text emails
• other

Context

A mailing template may be built to work in various different contexts.

• Contact person only (name address, etc.)
  • Reviews and appeals
• Information Request where the dates (including due date), short descriptions, subject, exemptions, department, owners and applicants and much more information may be merged in specific to that IR.
• Activity (task within an activity with a specific owner or team to respond in a department
• Breach

Subject Line

The subject line determines ti a significan extent whether an email will be opened. You can mail merge fields of data into the subject line of your email template.

The scope for automation of tasks is enormous with smart mail merged correspondence available in a couple of clicks.

The documents created are also auto-attached to the Information Request. If you have AXLR8 Messagestore then incoming and outgoing emails will be stored against the Information Request, too.

Trigaware

There are also fully automated emails. These are in addition to the mail merged documents. They are launched by the AXLR8 Trigaware system which are preprogrammed on events. Examples include:

• auto acknowledgement to applicants including details of their request and the due date
• alert to the team handling responses
• reminders at 10 and 5 days before the due date for those esponsible
• alert when a department officer has added a File or Note to an Information Request.

Some clients have a two dozen of these set up containing alerts that change with conditions.

Trigaware auto emails are explained at length elsewhere.

Information Request Workflow Automation was introduced here as a way to improve productivity for public sector IG Teams. Some Use cases are listed. We show how one of them might be automated and how the User Permissions work to make sure only the correct people design and deploy the robots.

Proof of Identity Workflow Automation

The example below is a abridged schematic of SAR workflow. Obviously, there is much more to it and more detailed workflow charts can be found elsewhere on this site.

Automation steps

Typically, the process building this in to your AXLR8 IRMS starts with your requirements.

1. In Document Template Admin, build the messages for each stage in the medium desired.  Usually these will be emails, SMS Messages or Word documents. For example reminders using Trigaware™ after waiting for a PoID for a SAR.  The messaging can be simple or intelligent with personalisation and very specific conditional contents. (see smart messaging).
2. We set up a “custom event definition” (i.e. the point in your workflow at which you need the document to go to the client).
3. Define the Status Life Cycle: the next section describes how to define a time limit for a status and any status change that follows completion of that life cycle. The life (cycle) of a status is the time it runs for or period before it closes itself and kicks off the new status.

Stage 1 Messaging to match your status change requirement

These examples match the work flow above.

• Inform the applicant that the IG team need this from the applicant when the IR is set to “Clarification Requested”
• Then alert them that 20 days has passed and there are 20 days remaining before they will have to resubmit their request. This would happen when the Clarification Second Request auto launched itself.
• The IR will close when the 40 days end and there has been no Clarification (or PoID). A third Trigger email can be programmed to go out. It would inform the applicant that their IR is now closed. They will have to resubmit it if they still need the information.

Stage 2: Create Automated Information Request

The best way to accomplish your objectives for Information Request automations is to create new IR Statuses. The reason for this is that all existing IRs that are running with that status will suddenly automate. If that is OK with you, go for it. We will describe how you do that below but you should consider the safer route of creating and applying a new one.

Please refer to the screenshots below which show the update of an IR Status and the creation of a new one.
The existing IR Status called “SAR ID Requested” for this client could be upgraded by:

• adding the tick for Time limited Status
• adding a duration of 20 days
• selecting a carry on status (in this case it will “Final SAR Request”)
• ticking the box for Special User Access. (see “User Permissions” below)

So after 20 days from the initial request, the IR is automatically sent to the next status of a final 20 days where they are on notice that the IR will be closed after that period. This is a total of 40 days. Very reasonable if you automate some reminders for the applicant as well.

In the above example, we updated and existing IR Status for our first 20 day SAR Request for PoID. Below we have created a new Information Request Status, also 20 days in duration and the last 20 day period they have in which to prove they are who they say they are before work starts finding their requested information. In the green box, to confirm the process above, we did the same ticks and duration. The difference is that the end of the 20 days automatically changes the status to Cancelled by Requester. Again, your organisation may have different vocabulary. You might call that “Failed to supply PoID” or some other label. In any case, it would close the IR because this final status would be a “finished” status.

So, we now have a “chain” of three actions that will hand over like a relay race with no human intervention necessary until PoID is received and agreed as valid, one day. Then the automated process is stopped and work begins with that request.

NB in the above example, you will see that this IR Status is disabled (tick box at the top). That is because We have not yet applied user permissions (or tested it).

Note. It is best not to apply the time limited status settings to existing IR statuses unless you are confident you know the outcome.  The next time it runs, it would run on all the existing IR records that have that existing status. Do you want that?  If you do make a status time limited, it would be best to search to see how many IR’s have that status, and understand that if they were given it more than the duration number of “valid” days ago, that “it will” change the status next time it runs.

Stage 3. Review User Permissions

Not all users should have the authority or expertise to apply a timed status. They may launch a wrong workflow automation. For example, without knowing the next steps, they could create an infinite loop. Users need to have the new user permission to apply one of these time limited statuses when they are first created. Later, when ta few runs through have proven the automations, you can remove the restriction from the IR status. This is done by removing the “Special User Access” shown in the screenshots in the previous stage. Below is how we can set up a knowledgeable pilot user to be able to use the new timed IR Statuses.

There is a new User Permission. It is called “Can apply Special User Access Statuses”, on user admin. Here is an example from a real client showing where it is on the User Admin screen.

If a User tries to apply a Time Limited IR Status to an Information Request, they may not be able to do so. If they do not have permission, they will get the following message.

For someone with this permission, the above alert message (example from City of Edinburgh) will not appear. That User can save their chosen status.

Systems Admin Permissions

As described above, your Super Users may decide which Users may apply these IR Statuses with timings built in. I.e. the “special User Access” IR statuses.

We have disabled update rights for clients but you have complete visibility of information Request Statuses. You can request an AXLR8 consultant to make the change.  Thus in your office, similar to the Dropdowns admin for Request Type, the Dropdowns Admin for Information Request Status only has a Save function when one of our consultants is using it. 
It is not available from client offices. AXLR8 have retained some of the administrative privileges for our support specialists for Request Status Admin.

The “Save” function in Information Request Status “Dropdowns Admin” was always available for Super Users at our clients. However, the ability to save changes in Request Type was reserved for AXLR8 consultants. The reason was the cost to us of fixing mistakes. With the power of this new Workflow automation we need to work with a few clients to take responsibility and shoulder the expense of any errors before handing back the ability to save changes. We also assume most client Super Users would wish to work over a Teams meeting screenshare with an AXLR8 support consultant when building these IR Automations. The reason is that mistakes can be costly to fix.

Audit Log

In the audit log view we can see the Cancelled status is a “Close” status, the save object has also set the “Date Closed” date (same as if you set the IR to cancelled in the IR details screen).

Short answer, anything you want during any timescale you can afford.

However, this is a standard AXLR8 demo of 48 minutes plus questions.

Items such as migration from legacy systems and security and other areas of compliance required in the public sector will be dealt with in depth if required at a later stage.

Other tools

If of interest, we can always look at other IG tools later Data Breach, DPIA, Information Asset Register, Data Sharing Policy Register, etc.  Also, Complaints Processing and other workflows.

Information Request Workflow Automation was introduced here as a way to improve productivity for public sector IG Teams. Some Use cases are listed. We show how one of them might be automated and how the User Permissions work to make sure only the correct people design and deploy the robots.

Proof of Identity Workflow Automation

The example below is a abridged schematic of SAR workflow. Obviously, there is much more to it and more detailed workflow charts can be found elsewhere on this site.

Automation steps

Typically, the process building this in to your AXLR8 IRMS starts with your requirements.

1. In Document Template Admin, build the messages for each stage in the medium desired.  Usually these will be emails, SMS Messages or Word documents. For example reminders using Trigaware™ after waiting for a PoID for a SAR.  The messaging can be simple or intelligent with personalisation and very specific conditional contents. (see smart messaging).
2. We set up a “custom event definition” (i.e. the point in your workflow at which you need the document to go to the client).
3. Define the Status Life Cycle: the next section describes how to define a time limit for a status and any status change that follows completion of that life cycle. The life (cycle) of a status is the time it runs for or period before it closes itself and kicks off the new status.

Stage 1 Messaging to match your status change requirement

These examples match the work flow above.

• Inform the applicant that the IG team need this from the applicant when the IR is set to “Clarification Requested”
• Then alert them that 20 days has passed and there are 20 days remaining before they will have to resubmit their request. This would happen when the Clarification Second Request auto launched itself.
• The IR will close when the 40 days end and there has been no Clarification (or PoID). A third Trigger email can be programmed to go out. It would inform the applicant that their IR is now closed. They will have to resubmit it if they still need the information.

Stage 2: Create Automated Information Request

The best way to accomplish your objectives for Information Request automations is to create new IR Statuses. The reason for this is that all existing IRs that are running with that status will suddenly automate. If that is OK with you, go for it. We will describe how you do that below but you should consider the safer route of creating and applying a new one.

Please refer to the screenshots below which show the update of an IR Status and the creation of a new one.
The existing IR Status called “SAR ID Requested” for this client could be upgraded by:

• adding the tick for Time limited Status
• adding a duration of 20 days
• selecting a carry on status (in this case it will “Final SAR Request”)
• ticking the box for Special User Access. (see “User Permissions” below)

So after 20 days from the initial request, the IR is automatically sent to the next status of a final 20 days where they are on notice that the IR will be closed after that period. This is a total of 40 days. Very reasonable if you automate some reminders for the applicant as well.

In the above example, we updated and existing IR Status for our first 20 day SAR Request for PoID. Below we have created a new Information Request Status, also 20 days in duration and the last 20 day period they have in which to prove they are who they say they are before work starts finding their requested information. In the green box, to confirm the process above, we did the same ticks and duration. The difference is that the end of the 20 days automatically changes the status to Cancelled by Requester. Again, your organisation may have different vocabulary. You might call that “Failed to supply PoID” or some other label. In any case, it would close the IR because this final status would be a “finished” status.

So, we now have a “chain” of three actions that will hand over like a relay race with no human intervention necessary until PoID is received and agreed as valid, one day. Then the automated process is stopped and work begins with that request.

NB in the above example, you will see that this IR Status is disabled (tick box at the top). That is because We have not yet applied user permissions (or tested it).

Note. It is best not to apply the time limited status settings to existing IR statuses unless you are confident you know the outcome.  The next time it runs, it would run on all the existing IR records that have that existing status. Do you want that?  If you do make a status time limited, it would be best to search to see how many IR’s have that status, and understand that if they were given it more than the duration number of “valid” days ago, that “it will” change the status next time it runs.

Stage 3. Review User Permissions

Not all users should have the authority or expertise to apply a timed status. They may launch a wrong workflow automation. For example, without knowing the next steps, they could create an infinite loop. Users need to have the new user permission to apply one of these time limited statuses when they are first created. Later, when ta few runs through have proven the automations, you can remove the restriction from the IR status. This is done by removing the “Special User Access” shown in the screenshots in the previous stage. Below is how we can set up a knowledgeable pilot user to be able to use the new timed IR Statuses.

There is a new User Permission. It is called “Can apply Special User Access Statuses”, on user admin. Here is an example from a real client showing where it is on the User Admin screen.

If a User tries to apply a Time Limited IR Status to an Information Request, they may not be able to do so. If they do not have permission, they will get the following message.

For someone with this permission, the above alert message (example from City of Edinburgh) will not appear. That User can save their chosen status.

Systems Admin Permissions

As described above, your Super Users may decide which Users may apply these IR Statuses with timings built in. I.e. the “special User Access” IR statuses.

We have disabled update rights for clients but you have complete visibility of information Request Statuses. You can request an AXLR8 consultant to make the change.  Thus in your office, similar to the Dropdowns admin for Request Type, the Dropdowns Admin for Information Request Status only has a Save function when one of our consultants is using it. 
It is not available from client offices. AXLR8 have retained some of the administrative privileges for our support specialists for Request Status Admin.

The “Save” function in Information Request Status “Dropdowns Admin” was always available for Super Users at our clients. However, the ability to save changes in Request Type was reserved for AXLR8 consultants. The reason was the cost to us of fixing mistakes. With the power of this new Workflow automation we need to work with a few clients to take responsibility and shoulder the expense of any errors before handing back the ability to save changes. We also assume most client Super Users would wish to work over a Teams meeting screenshare with an AXLR8 support consultant when building these IR Automations. The reason is that mistakes can be costly to fix.

Audit Log

In the audit log view we can see the Cancelled status is a “Close” status, the save object has also set the “Date Closed” date (same as if you set the IR to cancelled in the IR details screen).

Sometimes the original Information Request Type must change. What happens to the Due Date?
The most obvious example is when you log an FOI request thinking it is simple and it turns out to be more complex. It might be that clarification by the applicant expands the scope or the department providing some or all of the expertise explains an unforseen depth and raises more questions than answers.

Example 1: FOI changes to FOI Extended

An FOI request allows you 20 working days to respond. Bank Holidays in your jurisdiction and weekends are excluded. If a request is complex or more time is required, you may be able to extend that response time to 40 working days. In some jurisdictions there may also be 60 day FOI periods.
You can start with an FOI request and realise at some point that it will not be as simple to respond as had originally been thought. Therefore, you can change it to an “FOI Extended” with 40 days to respond. The AXLR8 system will then take the days that have already run and recalculate the new due date and hence the days outstanding wil have 20 days added on.

Let us take a simple example. FOI Request 1234 comes in and is set as an FOI 20 request type. The code indicates that it is and FOI request and has 20 working dats to run. It comes in on 11/04/2025, the day I am writing this FAQ. The due date will become 14/05/2025. Please note I took this from Demoshire2 which is presently set to English Bank Holidays in 2025 ( April 18 & 21, May 5 & 26 and Aug 25th). Assume for now that no restart for Clarification was required.

Let’s say it runs for 5 working days. Now, there are 15 working days left. I decide it is a 40 day FOI request instead. Then the clock will keep the days already used but the due date will be calculated as if it had been a 40 day request in the first place. So, it will change the due date to 12/06/2025. and the countdown will change from 15 days left to 35 days left. You can see why the public holidays were mentioned above!

Example 2: FOI changes to DPA Access then to DPA Access Extended

This was a real query from a client.

“We also have a query about request types changing throughout the request life, and how this changes the due date on requests (e.g. if a request is first thought to be FOISA , then changed to DPA – Access request and then changed to DPA – Access complex).“

We can use this as an example and apply the principles above. Same public holidays for simplicity even though this actually came from a different jurisdiction – Scotland whose bank holidays are different as yours may be. We have applied the rule that a response last day for a DPA/SAR may not fall on a weekend or bank holiday.

NB Please assume that any clarification or proof of ID has taken place beforehand. If it had not, the system would deal with those legitimate delays. It recalculates the Due Date as events take place.

AXLR8 are enhancing the system to work with calendar months. Choosing 28 days is accepted by most jurisdictions ( e.g. OIC). However, our feedback is that clients would prefer precise calendar months. This means that an IG team can complete a request in a 31 day month in 29 or 30 days. KPI reports will not show it as late. This new development is expected soon.

Example 3: May 25th 2018 – introduction of GDPR

The rules all changed for GDPR. AXLR8 just made the SAR requests starting on that Friday morning of the 25th run for a month. This is still the rule. Previously you were allowed 40 calendar days.

Every DPA request logged before midnight on 24th ran through to the end of its 40 day pre-GDPR processing time. So, AXLR8 made this enormous transition without any adverse results or extra charges.

Additional extended periods for more demanding SARS could also be chosen after that time.

Audit Trail

NB the changes made will be in the audit trail and so there is a visible “journey”. You can track how and when, the Coundown and Due Date has changed. It also shows which user made those changes.

KPIs

The Reports will accurately present the statistics. For example, it will show those responses which were late or on time and by how many days.

Questions?

You may have other examples and wish to play them through our system to check them.

Please do not hestiate to ask.

Short answer, anything you want during any timescale you can afford.

However, this is a standard AXLR8 demo of 48 minutes plus questions.

Items such as migration from legacy systems and security and other areas of compliance required in the public sector will be dealt with in depth if required at a later stage.

Other tools

If of interest, we can always look at other IG tools later Data Breach, DPIA, Information Asset Register, Data Sharing Policy Register, etc.  Also, Complaints Processing and other workflows.

There are several approaches you can take. Here are the three most popular.

Make it a Sensitive FOI

This is an FOI request that requires personal data in the answer which you feel should be protected as if it were a SAR.

A question about several streets might be FOI but a question a bout a specific house identifies a resident and may thus include PII.

Let’s say there are 5 parts to a question which is about compensation of nurses. Part 3 asks you about the applicant’s specific compensation but the rest are about general rules and amounts over the last couple of years.

In both examples one may chjoose to use a “Sensitive FOI”. That request type should be configured as “Private” and hence it will not

1. appear in the PDL (Public Disclosure Log)
2. be visible to staff with out access to Private Request Types

Make it a SAR

It may be that the request is so peculiar to a person that it is really a SAR. This happens occasionally and is a natural solution which immediately covers you for any possibility that the data will be published outside your organisation. It will also not be seen by those without “Private” Request Type access.

Make two IRs: a SAR and and EIR

There may be a number of questions in the IR and you can create two IRs. Let us take the above example with 5 parts. Part 3 could be a SAR and parts 1,2,4&5 could be sent out in a second IR which was classified as an FOI request.

Which to choose?

Obviously, the first is the simplest. The advantages of a “sensitive” FOI (FOISA, EIR, etc.) are that they are excluded from the Public Disclosure Log and are not seen by any staff whose access excludes Private request types.

The automated emails will have been set up so that they do not expose PII in the wrong places. Policies and workflow procedures would need to be in place so that the information management team know to make the subject line “Bill Smith’s Compensation” (in the above example). Rather they might make the correspondence subject “Potholes Compensation”.

The only other thing to consider is triage speed. Once you have set an IR as FOI, some automated triggers may have been launched. That needs to be taken into account before changing the request to a Sensitive FOI or SAR after a week of activity. Occasionally, however, it is not obvious for an officer at first. Senior staff are not present and a mistake is made.

What if I change IR Types during a response period?

There is a related article about what happens to the Countdown and Due Date when you change and IR Type from FOI to SAR.

What are Private Request Types?

Generally, these Requests would be SARs, Sensitive FOIs and some that are specific to different jurisdictions. Examples include: CAFCAS in UK and Procurator Fiscal in Scotland.

Please see the FAQ article about configuring Request Types. It explains how their behaviour differs in the AXLR8 system.

Short answer, anything you want during any timescale you can afford.

However, this is a standard AXLR8 demo of 48 minutes plus questions.

Items such as migration from legacy systems and security and other areas of compliance required in the public sector will be dealt with in depth if required at a later stage.

Other tools

If of interest, we can always look at other IG tools later Data Breach, DPIA, Information Asset Register, Data Sharing Policy Register, etc.  Also, Complaints Processing and other workflows.

There are several approaches you can take. Here are the three most popular.

Make it a Sensitive FOI

This is an FOI request that requires personal data in the answer which you feel should be protected as if it were a SAR.

A question about several streets might be FOI but a question a bout a specific house identifies a resident and may thus include PII.

Let’s say there are 5 parts to a question which is about compensation of nurses. Part 3 asks you about the applicant’s specific compensation but the rest are about general rules and amounts over the last couple of years.

In both examples one may chjoose to use a “Sensitive FOI”. That request type should be configured as “Private” and hence it will not

1. appear in the PDL (Public Disclosure Log)
2. be visible to staff with out access to Private Request Types

Make it a SAR

It may be that the request is so peculiar to a person that it is really a SAR. This happens occasionally and is a natural solution which immediately covers you for any possibility that the data will be published outside your organisation. It will also not be seen by those without “Private” Request Type access.

Make two IRs: a SAR and and EIR

There may be a number of questions in the IR and you can create two IRs. Let us take the above example with 5 parts. Part 3 could be a SAR and parts 1,2,4&5 could be sent out in a second IR which was classified as an FOI request.

Which to choose?

Obviously, the first is the simplest. The advantages of a “sensitive” FOI (FOISA, EIR, etc.) are that they are excluded from the Public Disclosure Log and are not seen by any staff whose access excludes Private request types.

The automated emails will have been set up so that they do not expose PII in the wrong places. Policies and workflow procedures would need to be in place so that the information management team know to make the subject line “Bill Smith’s Compensation” (in the above example). Rather they might make the correspondence subject “Potholes Compensation”.

The only other thing to consider is triage speed. Once you have set an IR as FOI, some automated triggers may have been launched. That needs to be taken into account before changing the request to a Sensitive FOI or SAR after a week of activity. Occasionally, however, it is not obvious for an officer at first. Senior staff are not present and a mistake is made.

What if I change IR Types during a response period?

There is a related article about what happens to the Countdown and Due Date when you change and IR Type from FOI to SAR.

What are Private Request Types?

Generally, these Requests would be SARs, Sensitive FOIs and some that are specific to different jurisdictions. Examples include: CAFCAS in UK and Procurator Fiscal in Scotland.

Please see the FAQ article about configuring Request Types. It explains how their behaviour differs in the AXLR8 system.

Short answer, anything you want during any timescale you can afford.

However, this is a standard AXLR8 demo of 48 minutes plus questions.

Items such as migration from legacy systems and security and other areas of compliance required in the public sector will be dealt with in depth if required at a later stage.

Other tools

If of interest, we can always look at other IG tools later Data Breach, DPIA, Information Asset Register, Data Sharing Policy Register, etc.  Also, Complaints Processing and other workflows.

This is accomplished in Document Template Admin.
To find Document Template Admin, please select Admin menu (cog on LHS menu in the old system or Super User menu in the new UX). Then select Document Template Admin.
There you will see a list of documents already available.

Medium

• Letter
• Email
• Text (SMS) Message
• Other

File Types

The format of the email will allow it to present and send in diferent ways.

• .RTF that can be opened by a wide variety of document readers including MS Word
• .HTML for formatted emails with colours and different highlights, fonts, embedded hyperlinks
• .TXT for plain text emails
• other

Context

A mailing template may be built to work in various different contexts.

• Contact person only (name address, etc.)
  • Reviews and appeals
• Information Request where the dates (including due date), short descriptions, subject, exemptions, department, owners and applicants and much more information may be merged in specific to that IR.
• Activity (task within an activity with a specific owner or team to respond in a department
• Breach

Subject Line

The subject line determines ti a significan extent whether an email will be opened. You can mail merge fields of data into the subject line of your email template.

The scope for automation of tasks is enormous with smart mail merged correspondence available in a couple of clicks.

The documents created are also auto-attached to the Information Request. If you have AXLR8 Messagestore then incoming and outgoing emails will be stored against the Information Request, too.

Trigaware

There are also fully automated emails. These are in addition to the mail merged documents. They are launched by the AXLR8 Trigaware system which are preprogrammed on events. Examples include:

• auto acknowledgement to applicants including details of their request and the due date
• alert to the team handling responses
• reminders at 10 and 5 days before the due date for those esponsible
• alert when a department officer has added a File or Note to an Information Request.

Some clients have a two dozen of these set up containing alerts that change with conditions.

Trigaware auto emails are explained at length elsewhere.

Messagestore takes a copy of all relevant email messages that enter and leave your business. For example, you might be set up to take any email to or from foi@yourorganisation.gov.uk and dataprotection@yourorganisation.gov.uk.

Messagestore then files them against the recipients and senders and the information request unique identifiers. The unique identifiers are coded into the subject lines in the email templates and the numbers and short descriptions are mail merged in.

This is described in greater detail together with “use cases”, blogs and articles on the messagestore.co.uk specialist website.

Merging IR references into the email subject line

The subject line of emails can have mailmerged data in them in the same way as you mail merge data into the body of a document.

The mailmerge templates are created and maintained in Document Template Admin.

Messagestore and Email2IR

Messagestore provides the platform for AXLR8’s Email2IR functionality. Email2IR checks Messagestore for any incoming email and creates a new IR ready for human management decisions:

1. request type (or you can clik the “Spam” button) and
2. the applicant (add new or allocate to a previous “frequent flier”).

If there is an exisiting IR reference in the subject line of the incoming email, then that incoming email does not create a new IR. The process checks for whether the email is about an exisiting IRs. It accomplishes this by reading the subject line. If there is and IR code in it, then it will add it to the “job bag” for that IR.

Please call if you need any training on this area or have any concerns about controlling visibility of emails for different groups of users.

This is accomplished in Document Template Admin.
To find Document Template Admin, please select Admin menu (cog on LHS menu in the old system or Super User menu in the new UX). Then select Document Template Admin.
There you will see a list of documents already available.

Medium

• Letter
• Email
• Text (SMS) Message
• Other

File Types

The format of the email will allow it to present and send in diferent ways.

• .RTF that can be opened by a wide variety of document readers including MS Word
• .HTML for formatted emails with colours and different highlights, fonts, embedded hyperlinks
• .TXT for plain text emails
• other

Context

A mailing template may be built to work in various different contexts.

• Contact person only (name address, etc.)
  • Reviews and appeals
• Information Request where the dates (including due date), short descriptions, subject, exemptions, department, owners and applicants and much more information may be merged in specific to that IR.
• Activity (task within an activity with a specific owner or team to respond in a department
• Breach

Subject Line

The subject line determines ti a significan extent whether an email will be opened. You can mail merge fields of data into the subject line of your email template.

The scope for automation of tasks is enormous with smart mail merged correspondence available in a couple of clicks.

The documents created are also auto-attached to the Information Request. If you have AXLR8 Messagestore then incoming and outgoing emails will be stored against the Information Request, too.

Trigaware

There are also fully automated emails. These are in addition to the mail merged documents. They are launched by the AXLR8 Trigaware system which are preprogrammed on events. Examples include:

• auto acknowledgement to applicants including details of their request and the due date
• alert to the team handling responses
• reminders at 10 and 5 days before the due date for those esponsible
• alert when a department officer has added a File or Note to an Information Request.

Some clients have a two dozen of these set up containing alerts that change with conditions.

Trigaware auto emails are explained at length elsewhere.

Messagestore takes a copy of all relevant email messages that enter and leave your business. For example, you might be set up to take any email to or from foi@yourorganisation.gov.uk and dataprotection@yourorganisation.gov.uk.

Messagestore then files them against the recipients and senders and the information request unique identifiers. The unique identifiers are coded into the subject lines in the email templates and the numbers and short descriptions are mail merged in.

This is described in greater detail together with “use cases”, blogs and articles on the messagestore.co.uk specialist website.

Merging IR references into the email subject line

The subject line of emails can have mailmerged data in them in the same way as you mail merge data into the body of a document.

The mailmerge templates are created and maintained in Document Template Admin.

Messagestore and Email2IR

Messagestore provides the platform for AXLR8’s Email2IR functionality. Email2IR checks Messagestore for any incoming email and creates a new IR ready for human management decisions:

1. request type (or you can clik the “Spam” button) and
2. the applicant (add new or allocate to a previous “frequent flier”).

If there is an exisiting IR reference in the subject line of the incoming email, then that incoming email does not create a new IR. The process checks for whether the email is about an exisiting IRs. It accomplishes this by reading the subject line. If there is and IR code in it, then it will add it to the “job bag” for that IR.

Please call if you need any training on this area or have any concerns about controlling visibility of emails for different groups of users.

There are several approaches you can take. Here are the three most popular.

Make it a Sensitive FOI

This is an FOI request that requires personal data in the answer which you feel should be protected as if it were a SAR.

A question about several streets might be FOI but a question a bout a specific house identifies a resident and may thus include PII.

Let’s say there are 5 parts to a question which is about compensation of nurses. Part 3 asks you about the applicant’s specific compensation but the rest are about general rules and amounts over the last couple of years.

In both examples one may chjoose to use a “Sensitive FOI”. That request type should be configured as “Private” and hence it will not

1. appear in the PDL (Public Disclosure Log)
2. be visible to staff with out access to Private Request Types

Make it a SAR

It may be that the request is so peculiar to a person that it is really a SAR. This happens occasionally and is a natural solution which immediately covers you for any possibility that the data will be published outside your organisation. It will also not be seen by those without “Private” Request Type access.

Make two IRs: a SAR and and EIR

There may be a number of questions in the IR and you can create two IRs. Let us take the above example with 5 parts. Part 3 could be a SAR and parts 1,2,4&5 could be sent out in a second IR which was classified as an FOI request.

Which to choose?

Obviously, the first is the simplest. The advantages of a “sensitive” FOI (FOISA, EIR, etc.) are that they are excluded from the Public Disclosure Log and are not seen by any staff whose access excludes Private request types.

The automated emails will have been set up so that they do not expose PII in the wrong places. Policies and workflow procedures would need to be in place so that the information management team know to make the subject line “Bill Smith’s Compensation” (in the above example). Rather they might make the correspondence subject “Potholes Compensation”.

The only other thing to consider is triage speed. Once you have set an IR as FOI, some automated triggers may have been launched. That needs to be taken into account before changing the request to a Sensitive FOI or SAR after a week of activity. Occasionally, however, it is not obvious for an officer at first. Senior staff are not present and a mistake is made.

What if I change IR Types during a response period?

There is a related article about what happens to the Countdown and Due Date when you change and IR Type from FOI to SAR.

What are Private Request Types?

Generally, these Requests would be SARs, Sensitive FOIs and some that are specific to different jurisdictions. Examples include: CAFCAS in UK and Procurator Fiscal in Scotland.

Please see the FAQ article about configuring Request Types. It explains how their behaviour differs in the AXLR8 system.

Short answer, anything you want during any timescale you can afford.

However, this is a standard AXLR8 demo of 48 minutes plus questions.

Items such as migration from legacy systems and security and other areas of compliance required in the public sector will be dealt with in depth if required at a later stage.

Other tools

If of interest, we can always look at other IG tools later Data Breach, DPIA, Information Asset Register, Data Sharing Policy Register, etc.  Also, Complaints Processing and other workflows.

Generally these would be SARs, Sensitive FOIs and some that are specific to different jurisdictions. Examples include: CAFCAS in UK and Procurator Fiscal in Scotland.

The Request Types in the AXLR8 system are completely customisable for any jurisdiction (or just because your organisation needs to). This means setting it up with the “Private” parameter set to “Yes”. It may also be that there are Request Types that are not private but may not be shown on the Public Disclosure Log. That can be set separately as you can see in the orange box below.

How does the AXLR8 system treat Private Request Types?

1. Only those with Private IR access may see them. This is different to the Application Blind parameter in User Admin which prevents a user seeing any applicant details, regardless of the type of request.
2. The automated emails can be set up differently. For example, the Subject line of email correspondence and file names of documents may say the Request Type and the unique reference number. For example the subject line might say “SAR- ACCESS demoshireIR:12345” but not the name of the applicant for who you are collecting the information. Compare this with the subject line for an FOI request which would say “Potholes vehicle damage compensation FY2023-4 DemoshireIR:12346“.
3. The Request will not show on the PDL (Public Disclosure Log) for your organisation.

Response Times

The response times are unaffected by the “Private” flag shown above. How these timings work as well as how they change with clarifications and proof of identity and other events is described elsewhere.

The time for completion is set elsewhere. A Sensitive FOI (assuming not extended) still runs to a deadline of 20 working days. A SAR still has a month regardless of bank holidays and weekends.

Short answer, anything you want during any timescale you can afford.

However, this is a standard AXLR8 demo of 48 minutes plus questions.

Items such as migration from legacy systems and security and other areas of compliance required in the public sector will be dealt with in depth if required at a later stage.

Other tools

If of interest, we can always look at other IG tools later Data Breach, DPIA, Information Asset Register, Data Sharing Policy Register, etc.  Also, Complaints Processing and other workflows.

Messagestore takes a copy of all relevant email messages that enter and leave your business. For example, you might be set up to take any email to or from foi@yourorganisation.gov.uk and dataprotection@yourorganisation.gov.uk.

Messagestore then files them against the recipients and senders and the information request unique identifiers. The unique identifiers are coded into the subject lines in the email templates and the numbers and short descriptions are mail merged in.

This is described in greater detail together with “use cases”, blogs and articles on the messagestore.co.uk specialist website.

Merging IR references into the email subject line

The subject line of emails can have mailmerged data in them in the same way as you mail merge data into the body of a document.

The mailmerge templates are created and maintained in Document Template Admin.

Messagestore and Email2IR

Messagestore provides the platform for AXLR8’s Email2IR functionality. Email2IR checks Messagestore for any incoming email and creates a new IR ready for human management decisions:

1. request type (or you can clik the “Spam” button) and
2. the applicant (add new or allocate to a previous “frequent flier”).

If there is an exisiting IR reference in the subject line of the incoming email, then that incoming email does not create a new IR. The process checks for whether the email is about an exisiting IRs. It accomplishes this by reading the subject line. If there is and IR code in it, then it will add it to the “job bag” for that IR.

Please call if you need any training on this area or have any concerns about controlling visibility of emails for different groups of users.

Short answer, anything you want during any timescale you can afford.

However, this is a standard AXLR8 demo of 48 minutes plus questions.

Items such as migration from legacy systems and security and other areas of compliance required in the public sector will be dealt with in depth if required at a later stage.

Other tools

If of interest, we can always look at other IG tools later Data Breach, DPIA, Information Asset Register, Data Sharing Policy Register, etc.  Also, Complaints Processing and other workflows.

This is accomplished in Document Template Admin.
To find Document Template Admin, please select Admin menu (cog on LHS menu in the old system or Super User menu in the new UX). Then select Document Template Admin.
There you will see a list of documents already available.

Medium

• Letter
• Email
• Text (SMS) Message
• Other

File Types

The format of the email will allow it to present and send in diferent ways.

• .RTF that can be opened by a wide variety of document readers including MS Word
• .HTML for formatted emails with colours and different highlights, fonts, embedded hyperlinks
• .TXT for plain text emails
• other

Context

A mailing template may be built to work in various different contexts.

• Contact person only (name address, etc.)
  • Reviews and appeals
• Information Request where the dates (including due date), short descriptions, subject, exemptions, department, owners and applicants and much more information may be merged in specific to that IR.
• Activity (task within an activity with a specific owner or team to respond in a department
• Breach

Subject Line

The subject line determines ti a significan extent whether an email will be opened. You can mail merge fields of data into the subject line of your email template.

The scope for automation of tasks is enormous with smart mail merged correspondence available in a couple of clicks.

The documents created are also auto-attached to the Information Request. If you have AXLR8 Messagestore then incoming and outgoing emails will be stored against the Information Request, too.

Trigaware

There are also fully automated emails. These are in addition to the mail merged documents. They are launched by the AXLR8 Trigaware system which are preprogrammed on events. Examples include:

• auto acknowledgement to applicants including details of their request and the due date
• alert to the team handling responses
• reminders at 10 and 5 days before the due date for those esponsible
• alert when a department officer has added a File or Note to an Information Request.

Some clients have a two dozen of these set up containing alerts that change with conditions.

Trigaware auto emails are explained at length elsewhere.

Messagestore takes a copy of all relevant email messages that enter and leave your business. For example, you might be set up to take any email to or from foi@yourorganisation.gov.uk and dataprotection@yourorganisation.gov.uk.

Messagestore then files them against the recipients and senders and the information request unique identifiers. The unique identifiers are coded into the subject lines in the email templates and the numbers and short descriptions are mail merged in.

This is described in greater detail together with “use cases”, blogs and articles on the messagestore.co.uk specialist website.

Merging IR references into the email subject line

The subject line of emails can have mailmerged data in them in the same way as you mail merge data into the body of a document.

The mailmerge templates are created and maintained in Document Template Admin.

Messagestore and Email2IR

Messagestore provides the platform for AXLR8’s Email2IR functionality. Email2IR checks Messagestore for any incoming email and creates a new IR ready for human management decisions:

1. request type (or you can clik the “Spam” button) and
2. the applicant (add new or allocate to a previous “frequent flier”).

If there is an exisiting IR reference in the subject line of the incoming email, then that incoming email does not create a new IR. The process checks for whether the email is about an exisiting IRs. It accomplishes this by reading the subject line. If there is and IR code in it, then it will add it to the “job bag” for that IR.

Please call if you need any training on this area or have any concerns about controlling visibility of emails for different groups of users.

Messagestore takes a copy of all relevant email messages that enter and leave your business. For example, you might be set up to take any email to or from foi@yourorganisation.gov.uk and dataprotection@yourorganisation.gov.uk.

Messagestore then files them against the recipients and senders and the information request unique identifiers. The unique identifiers are coded into the subject lines in the email templates and the numbers and short descriptions are mail merged in.

This is described in greater detail together with “use cases”, blogs and articles on the messagestore.co.uk specialist website.

Merging IR references into the email subject line

The subject line of emails can have mailmerged data in them in the same way as you mail merge data into the body of a document.

The mailmerge templates are created and maintained in Document Template Admin.

Messagestore and Email2IR

Messagestore provides the platform for AXLR8’s Email2IR functionality. Email2IR checks Messagestore for any incoming email and creates a new IR ready for human management decisions:

1. request type (or you can clik the “Spam” button) and
2. the applicant (add new or allocate to a previous “frequent flier”).

If there is an exisiting IR reference in the subject line of the incoming email, then that incoming email does not create a new IR. The process checks for whether the email is about an exisiting IRs. It accomplishes this by reading the subject line. If there is and IR code in it, then it will add it to the “job bag” for that IR.

Please call if you need any training on this area or have any concerns about controlling visibility of emails for different groups of users.

Short answer, anything you want during any timescale you can afford.

However, this is a standard AXLR8 demo of 48 minutes plus questions.

Items such as migration from legacy systems and security and other areas of compliance required in the public sector will be dealt with in depth if required at a later stage.

Other tools

If of interest, we can always look at other IG tools later Data Breach, DPIA, Information Asset Register, Data Sharing Policy Register, etc.  Also, Complaints Processing and other workflows.

Short answer, anything you want during any timescale you can afford.

However, this is a standard AXLR8 demo of 48 minutes plus questions.

Items such as migration from legacy systems and security and other areas of compliance required in the public sector will be dealt with in depth if required at a later stage.

Other tools

If of interest, we can always look at other IG tools later Data Breach, DPIA, Information Asset Register, Data Sharing Policy Register, etc.  Also, Complaints Processing and other workflows.

Short answer, anything you want during any timescale you can afford.

However, this is a standard AXLR8 demo of 48 minutes plus questions.

Items such as migration from legacy systems and security and other areas of compliance required in the public sector will be dealt with in depth if required at a later stage.

Other tools

If of interest, we can always look at other IG tools later Data Breach, DPIA, Information Asset Register, Data Sharing Policy Register, etc.  Also, Complaints Processing and other workflows.

Messagestore takes a copy of all relevant email messages that enter and leave your business. For example, you might be set up to take any email to or from foi@yourorganisation.gov.uk and dataprotection@yourorganisation.gov.uk.

Messagestore then files them against the recipients and senders and the information request unique identifiers. The unique identifiers are coded into the subject lines in the email templates and the numbers and short descriptions are mail merged in.

This is described in greater detail together with “use cases”, blogs and articles on the messagestore.co.uk specialist website.

Merging IR references into the email subject line

The subject line of emails can have mailmerged data in them in the same way as you mail merge data into the body of a document.

The mailmerge templates are created and maintained in Document Template Admin.

Messagestore and Email2IR

Messagestore provides the platform for AXLR8’s Email2IR functionality. Email2IR checks Messagestore for any incoming email and creates a new IR ready for human management decisions:

1. request type (or you can clik the “Spam” button) and
2. the applicant (add new or allocate to a previous “frequent flier”).

If there is an exisiting IR reference in the subject line of the incoming email, then that incoming email does not create a new IR. The process checks for whether the email is about an exisiting IRs. It accomplishes this by reading the subject line. If there is and IR code in it, then it will add it to the “job bag” for that IR.

Please call if you need any training on this area or have any concerns about controlling visibility of emails for different groups of users.