Intake process and data

[samschlicht]

As a TC user I would like a clear mandatory step to initiate and complete an intake So that there is no confusion as to our process, and also the data on intakes is reliable

As a TC dev I would like intake represented more concretely So that I have an easier time adding functionality that uses it

We did discuss making intake fields unavailable till the 'Start New Intake' or 'Update Intake' button is clicked — which on its face seems simple and unproblematic.

However, intakes are frequently not completed, either because a candidate proves to be ineligible or because the call is disrupted. So how do we know if an intake was actually completed? We do have a 'Complete Intake' button, but it's not a required step to press it, because the fields auto-save anyway. That's a useful feature, so how do we retain it while also ensuring that the outcome of an intake is always documented?

We know for certain that this feature is a cause for confusion among source team members, and people are using it differently, which puts a question mark on the data we're collecting.

A big part of the answer may simply be clarified page layout and instructions but we should look at root and branch.

The second story is separate but related — we currently 'know' an intake was completed because of the candidate note that gets created. But a) that relies on the slightly shaky process that I've outlined, and b) it isn't its own object and thereby more easily accessible.

Ideally we address some of these issues before the big push for bulking up our intake numbers!

[cazcam34]

I had a thought: Rewording the complete button to 'Mark as Complete', this indicates that it isn't required to submit the form (as it's autosave) but will imply that the benefit comes from giving the candidate a 'mark' This will allow the candidate to have an icon/flag to show which intakes have been completed, benefitting the user.

[camerojo]

Just some notes from our conversation

• Each candidate can have just one mini intake and one full intake
• We just record the first time an intake (mini or full) is completed (date time) and who by (user)
• Candidate notes continue to be recorded automatically when an intake is first completed
• Subsequent updates to intakes are possible, but that does not update the recorded date/user. If they want to record information about who did an extra update and when - or any other info, that can be recorded in a candidate note

Storing the first completion info

We talked about 3 fields per intake: date/time, user and text. However, can't we use the candidate note for the text?

If so, that means we only need to store 4 new fields on the candidate record: date/time, user for mini and full intake.

[samschlicht]

@camerojo agreed on all counts, I've nothing to add to this.

'Update intake' can absolutely be a candidate note — there's been some clamour to be able to reliably measure the amount of intakes someone (individual or partner org) has been doing over time, to help measure individual workload and process improvements. This approach would miss a wholesale intake re-do (the nuclear 'update'), but honestly, I don't think that happens that often and it could be captured anyway with a custom query (of the candidate notes) when necessary.

This gets us to a place where we can easily add this to search and start producing some useful stats, which is the core of the requests that we have so far.

[camerojo]

Just a note that what makes an intake different from any other process involving updating candidate data is that an intake is a concentrated focussed process with the candidate present either physically or being interviewed by phone or Zoom etc. That requires organising a 1 on 1 meeting with the candidate. This is all time consuming and difficult- which is why they are keen to record who does it.

Just subsequently updating some intake data doesn't need to be tracked I don't think. It is those key first meetings with a candidate that we are tracking, and I think that our approach above covers that.

[cazcam34]

Questions:

• Do we keep the 'Update Intake' button which just currently creates a note with the audit data? It could lead to confusion though, leading people to think it's updating the data on the TC. But it does help streamline/encourage the update process of making a note. AND on more thought, it will be required so that we have a standardised note title that we can then use to search on if we need to track updates. This should only show once the intake has been marked as completed (so disable the complete button and instead enable the update button) - YES WORTH KEEPING
• Do we comment out the update external intake button? This could be something we just comment out on the front end, but when needed (eg. Mindset recently) we have it all there to comment back. - ADD YAML FIELD AND DEPENDANT ON THIS
• And we no longer need the start intake button? Is there any purpose to creating a note that says when it was started (e.g. tracking time taken to complete?) - REMOVE FOR NOW, CAN ALWAYS ADD IF NEEDED

Add new YAML field for the input external intake - this button is then dependant on the yaml field.

[cazcam34]

Does this field need to be on ES? Answer YES

[cazcam34]

Flyways SQL needed:

alter table candidate add column mini_intake_completed_by bigint references users; alter table candidate add column mini_intake_completed_date timestamptz; alter table candidate add column full_intake_completed_by bigint references users; alter table candidate add column full_intake_completed_date timestamptz;

alter table saved_search add column mini_intake_completed boolean; alter table saved_search add column full_intake_completed boolean;

[samschlicht]

@cazcam34 just noting that as an addendum or the end to this issue, we should get rid of the SF candidate sync code and column on the search display that use the transient version of this data. Perhaps we should log that as a new issue? And out of curiosity, as a part of this issue, have you done the transfer of the old data to the new fields? Again, if not, perhaps that's a separate issue.

[cazcam34]

Should add 'interview' back to candidate note created - as this is currently used to count the intakes completed.

[cazcam34]

@samschlicht great points! No I haven't done a transfer of the old data.... woops. And once I've got it all working, I might create a new issue to remove the transient field, I also then need to add the new fields to SF. Ahh good spot, back to the drawing board thanks for pointing these out!!

[cazcam34]

SQL for updating new fields with existing intake data:

-- update FULL INTAKE COMPLETED BY update candidate as c set full_intake_completed_by = n.created_by from candidate_note n where (lower(n.title) LIKE '%full intake interview completed%' OR lower(title) LIKE '%full intake took place%' ) and c.id = n.candidate_id;

-- update MINI INTAKE COMPLETED BY update candidate as c set mini_intake_completed_by = n.created_by from candidate_note n where (lower(n.title) LIKE '%mini intake interview completed%' OR lower(title) LIKE '%mini intake took place%' ) and c.id = n.candidate_id;

-- update FULL INTAKE COMPLETED DATE update candidate as c set full_intake_completed_date = n.created_date from candidate_note n where (lower(n.title) LIKE '%full intake interview completed%' OR lower(title) LIKE '%full intake took place%' ) and c.id = n.candidate_id;

-- update MINI INTAKE COMPLETED DATE update candidate as c set mini_intake_completed_date = n.created_date from candidate_note n where (lower(n.title) LIKE '%mini intake interview completed%' OR lower(title) LIKE '%mini intake took place%' ) and c.id = n.candidate_id;