Redirect to third party

The Redirect to third party workflow can also be used with or without communicating with the third party from RefTracker, using all of the features described for the Refer to third party function on the previous page, as well as other methods. The following sections refer to the differences in these other functions only. So, see Refer to third party for more details about how to use the functions of this screen.

The purpose of the Redirect to third party function is to record the fact that a third party has been asked to handle this request, or to send details of this request to a third party so they can handle it. Details of the request can be sent by email, or by XML and a web service directly to another RefTracker system where a new request will be automatically created.

Importantly, if you need to let the client know about the step you are taking here, you can send them an email by using the partial answer or Answer functions build into this page. Your message to the client will NOT be sent to the client, if the Third party action is not successfully completed. Check the History screen if you have any concerns about whether the note to the client went out. You may wish to click [Preview] to see what it going to be sent out, before it goes!

As you are redirecting to another party (and may be absolving your organisation of responsibility for this question), the Redirect to third party function also provides the opportunity to close the question as it is redirected. Primary questions with open internal tasks cannot be closed, so the Close option will not show for those questions (a note will appear at the top of the screen explaining that the question cannot be closed until the open internal tasks are closed).

If you want to close the question, change the “Leave open” radio button to “Close”. You will see that the Closing status automatically goes to “Closed redirected” and the closing fields display, and the Question will be closed when you complete using this function. Note that requests with open Sub tasks cannot be closed, so the option to close does not display for requests with open sub tasks.

Even though Redirect means someone else takes responsibility for completing this question, you may want to keep the question open until you know the third party has done their work, in which case you should leave the “Leave open” radio button selected (and your note to the third party should clearly indicate that you want to be copied on the response). When you are happy that the third party has responded, just come back into this Third party Redirect function and close the question (it will automatically apply the “Closed – redirected” status), and compete any closing data collection like Expertise, Category, Closing comments, and Costs (and payments). Alternatively you can use “Close without client contact” in the menu list under Answer to finally close the question.

Note that when you select to close with status “Closed – redirected”, the question is simply closed – an Answer email is NOT sent to the client unless you specifically put text in the Answer email box. Redirect to third party workflows generally do not require an answer.

If you are sending an email to the third party as a part of your use of the Redirect to third party function, the email generated will include your contact details in case the third party needs to speak with you about your redirection. If they reply to the email their reply will be automatically included as an update to the question by RefTracker and you will be advised. If they reply directly to you, you will need to cut and paste their reply into this question by using one of the Answer screen functions such as Note.

Exercise

Try this workflow, it works in exactly the same way as the Refer to third party workflow that we just worked through in detail except that:

You need to make a decision about whether you want this question automatically closed as a result of having redirected it.
The client’s contact details are automatically included in the third party email generated by RefTracker (because the third party needs those details to be able to directly respond), so you need to be EXTRA careful about examining the email to the third party for any private information that should not be passed on to the third party.

Email sent to third party by Redirect process

The email sent to the third party by the Redirect to third party process asks them to contact the client directly and includes the client’s contact details. It also includes the contact details of the staff member allocated the question so that the third party can contact that staff member, if necessary.

The layout of this email is controlled by your System administrator so, the email sent by your system may be different to this one. It can be edited to remove any information that you do not want forwarded on to the third party. Removing the beginning or end of any line in this template can result in HTML formatting commands being lost (and errors created) so please avoid removing the beginning and end of lines.

Redirecting questions to other RefTracker systems

Redirect using the RefTracker to RefTracker method allows questions in your system to be transferred to another RefTracker system for response. You can only send to organisations that your System administrator has set up for RefTracker to RefTracker access and the option will not appear in the Redirect to third party screen until your System administrator has done the setup described below.

Guidelines for RefTracker to RefTracker setup by System administrator

To setup for RefTracker to RefTracker question transfer (also known as R2R), your System administrator needs to:

Add the Organisation to the Organisation code table (as type RefTracker to RefTracker) so you can send questions to that Organisation. See hints for setting up these entries in the Organisation section of the Other code tables help page.
Add the organisation to parameter 9.10 which allows them to send questions to you, including returning questions that you send, that they cannot address. For security of this transfer process, you must obtain a System key from any system that you want to receive requests by R2R from, and add that System key to your Acceptable domain for that site in parameter 9.10.
To do this, ask the system that wants to send requests to you, to provide the value in their parameter 9.1. You then need to add that value to that site’s domain in parameter 9.10, space separated and with a return following the system key.
Here’s an example of how to set this up:
The patchaus.altarama.com RefTracker system wants to send requests R2R to the english.altarama.com RefTracker system.
Parameter 9.1 is the patchaus system looks like this:

To add this mandatory security to the English.altarama.com system we add a space to the https://patchaus.altarama.com entry in parameter 9.10, and then paste in the key that our patchaus contact has given us from their parameter 9.1

Check that the RefTracker to RefTracker request form is set up as it is needed to control the attributes of questions arriving in this way, such as their target response date and allocation. Question attachments should be allowed in this form.
The RefTracker to RefTracker process presumes that you are sending an open question via this process, so some information recorded about that request is NOT accepted by the receiving R2R system (e.g the Answer field and Response date field, as Answers and Response dates set in the sending system are irrelevant). In the rare instance that you need to change what fields are received by your RefTracker to RefTracker process, you can amend the R2Rfilter.xml file in the config/exchange/refTracker/settings directory.
Further the R2Rfilter.xml file at config/exchange/refTracker/settings controls what fields are automatically written to the same fields in your system and which ones are only written to the same field if the labels for those fields match (if they do not match the data will be written to the “Other imported data” field for manual review).
Here’s an example R2RFilter.xml file.
Where the action attribute is set to “Exclude” that value will not be included in the data used to create the request in your system
Where the matchlabel attribute is set to “0” (or “false”) the data in that field will be saved into the same field in your RefTracker system, irrespective of the label that is used for it in the sending system.
Where the matchlabel attribute is set to “1” (or “true”) the data in that field will be saved into the “Other imported data field” if the label that is used for that field in the sending system is different to the one used in your system. This is done because the different labels might mean that the field is used for a different purpose in the sending system. Placing the data in the “Other imported data field” allows it to be manually checked by staff and placed in the most appropriate field.

Create some local policies and procedures based on the information below, about how staff should handle questions arriving, and being sent, in this way.

For testing purposes you can add your own domain – this will result in the question you are sending, creating a new question in your own system (the same system it was sent from).
If you have an issue with more data appearing in the “Other imported data” area than you would like, you should look at adjusting the “matchlabel” attributes in the R2RFilter.xml file described above.

Usage guidelines for staff using Redirect via RefTracker to RefTracker

To send a question to an organisation that also uses RefTracker, and have it arrive in their RefTracker system as a new question, select an organisation that has been set up for “RefTracker to RefTracker” communication, and select “Send to third party” at “Send option”.

You should enter your instructions to the Third party in the Workflow notes box.

Use “Partial answer” or “Answer” to let the client know what is happening, if appropriate, and then click on Save or Save & send.

The system will then show you the data it is about to send. The data is shown in XML format. This is how it will be sent to the receiving system, which will be able to extract the information and create a question in that system containing all of the information sent, and your Workflow note as the first history record in that question.

Only certain data about the request is sent from your system. Information specific to your system, such as the “Last update” field, is not sent. The format of the data being sent is XML and presents the information as<DDlabel>data held in that field</DDlabel>e.g. <email>info@altarama.com.au</email>

Your note will show at the end of the data – you can use the Send button at the top of the XML to have the question sent, or, review the XML and use the Send button at the end of that box to Send. You cannot change the XML (other than by Changing the question itself).

If the client provided any attachments with this question, the system will pop-up a reminder for you to check that it is appropriate to be passing on those attachments to the third party. If you do not want to send any you can click “Cancel” and untick them in the summary of attachments at the top of the “Record that will be sent” division, and then click on Send again.

The question will then be sent and a confirmation screen displayed that confirms success of the transfer (or otherwise). Any attachments provided by the client (Question attachments) will be sent with the question. It also sends the contact details of the staff member allocated with question so that the receiving system can contact that staff member about it if necessary.

Note that when a question is sent by this method, the status will be updated to “Redirected to third party”, and the “How complete” status that you choose, or the closing status you select (defaults to “Closed – redirected”).

Also a history entry will be created in that question recording that the question was sent using RefTracker to RefTracker transfer. The history entry includes the name of the organisation the question was transferred to, and the question number that was created in their system, so you can contact them about it if necessary.

What does the receiving system see?

Your question will arrive in the receiving system within seconds and be converted into a question that shows in that system’s Open question’s list. It will usually show as “Incomplete” which means that when you click on the question number it will take you to the Change screen so that you can check the “Other imported data field” for information that was not able to be directly mapped from the sending system’s fields to the receiving system’s fields.

The history entry for the question will clearly show that the question was received as a redirect from another RefTracker system.

Not all fields that are sent via R2R will be received into your system. Your system Administrator can adjust what fields are received or ignored, and whether the data will be mapped directly to your equivalent fields, or only mapped to that field if the label for that field is identical in both the sending and receiving systems.

When a direct mapping of the data received cannot be done, the received data is added to a field “Other Imported data” with the label for that data that was used in the sending system. Data can end up in this area because your system does not have an equivalent field to store that type of data, or because the data being sent contained a code table value not present in your equivalent code table.

Be sure to look at the “Other imported data” field as it can contain some important information about the question in the sending system, and about the sending system, in case you need to refer back to the sending organisation – such as that Organisation’s name, the question number in their system, their original Target response date, and contact details for the staff member who was responsible for passing this question on to your system.

Data presented in the “Other imported information” section is presented in four groups:

Source system – the data provides information in the receiving system about the sending system. It holds the name of the sending system and the details of the logged on user that performed the send.
Original data – this section shows data from the sending system that has been flagged as reference in the config file – such as the Request type in the sending system, and the Target date in the sending system. This information may be helpful in understanding how best to respond to this reqeust, but your receiving system will apply its own values to these fields.
Mismatched – shows fields where the label for the field did not match between the sending and receiving systems, or, where a code table value used in the sending system cannot be matched to a value (description) for that code table field in your receiving system.
Rejected – This shows fields that were rejected the exchange mechanism has encountered an error in dealing with that field, for example where a field exists in the sending system but no equivalent field is available in the receiving system.

To make this “other” information obvious, the status of the question will be “incomplete” and a message saying that the question “needs verification” will automatically appear when the Change screen is used. If the “Other imported data” includes any data, it will appear in the Receipt information division of the Change screen until you save something into the question using the Change screen.

According to the settings in the R2RFilter.xml file (System administrators can find it at config/exchange/refTracker/settings), the rules for how data is mapped are:

Only data fields allowed by your R2RFilter file will be used to create the request in your system, from the data sent to you by RefTracker to RefTracker. Excluded data (usually the Answer field is one of these,) is not brought into your system.
Data is mapped to the identical field in the RefTracker data dictionary, as long as the field has the same Data dictionary label in both systems (except for some fields that are specified as exceptions in your R2RFilter file).
If the field cannot be mapped it is added to the data provided in the “Mismatched data” section of the “Other imported data” field with a label indicating the label that was used for it in the sending system.

How to respond to this question

This imported question is the same as any other question in RefTracker and can be responded to in the same way.

However the chances of the imported data not exactly matching how you would want it represented in your system is high. For this reason imported questions are clearly identified as such in your Open question screen and appear with an incomplete icon. the incomplete status means that when you click on the question number, you will be taken to the Change screen, where the “Other imported data” field will be showing in the Receipt information division of the screen so that you can be manually map any information not able to be automatically mapped, the the correct field, before starting work on a response.

The Unallocated (imported) status of these questions is hyperlinked to the Correspondence tab of the Answer screen to ensure that you can quickly see any note sent with the Question.

We recommend that the workflow for dealing with questions that have arrived via RefTracker to RefTracker is:

Click on the question number in the Open questions screen. You will be taken to the Change screen where you can familiarise yourself with the question.
Check the “Other imported data” field in the Receipt information division at the top of this screen for information that was not able to be automatically mapped – and information about the sender.
Decide whether your organisation should respond to this question or whether it should be returned to the sending organisation. (If it needs to be returned use Redirect and the RefTracker to RefTracker method with an note describing why it needs to be returned.)
If retaining, use the Change screen to adjust any attributes of the question such as information in the “Other imported data” fields that you want to map to specific fields that you use – you may even want to change to a different request form. Also check the Target response date, it may need adjusting if you want to take the target date from the original system into account.
Use Inform client in the Answer screen to let the client know that you will be responding to their question, and by when, if your System administrator has not set up your system to have a confirmation email sent to the client automatically on arrival of these types of questions.
Then allocate the question to an appropriate staff member for response.

What if you are transferred a question that you cannot respond to

The RefTracker to RefTracker system transfer works on the basis that the receiving system WILL answer the question. If you receive a question that you cannot answer, the appropriate protocol is to transfer the question back to the sending library with an explanation as to why it cannot be answered by your organisation.

When a question you have sent out is returned to you, it will arrive as a new question. Your organisation’s name will appear at the top of the “Other imported data” field, and the returning organisations details will be below them. Your organisation’s name appearing here should draw your attention to the fact that this is a return. You will need to go back to the original question (the question number will be showing in the Other imported data field) and address it again (and when you have addressed it you may want to ask your Supervisor to delete the returned question after you have closed it).