Open samschlicht opened 1 week ago
Ooh, need to take a look at this scheduled method:
First thing I've done is remove the scheduled call to JobService.updateOpenJobs. The method and its SystemAdminApi stub may have some future utility, but we don't want it called automatically on schedule.
I also note that in SalesforceJobOppServiceImpl.copyOpportunityToJobOpp(), we accept whatever stage the SF opp has, as long it's valid:
try {
stage = JobOpportunityStage.textToEnum(op.getStageName());
} catch (IllegalArgumentException e) {
LogBuilder.builder(log)
.action("UpdateJobOpp")
.message("Error decoding stage in update: " + op.getStageName())
.logError(e);
stage = JobOpportunityStage.prospect;
}
salesforceJobOpp.setStage(stage);
Then, in JobService.publishJob(), we will advance the stage to Candidate Search if it was previously at an earlier stage:
final JobOpportunityStage stage = job.getStage();
if (stage.compareTo(JobOpportunityStage.candidateSearch) < 0 ) {
//Current stage is before CandidateSearch so update it to CandidateSearch here
job.setStage(JobOpportunityStage.candidateSearch);
//Update Salesforce stage to match - setting Next Step and Due date
final LocalDate submissionDueDate = job.getSubmissionDueDate();
I would suggest that the above is not really an issue, as long as we don't enable continuing transfer from SF to TC.
So, for me the next step here is to identify other open jobs that are unpublished on the TC:
select * from salesforce_job_opp where published_date is null and closed is false;
Turns out there are 28: unpublishedLiveJobs.xlsx
Will discuss next steps with team, we may want to make some sort of communication reminding folks to update jobs on TC.
Not to shame anyone, but here's a descriptive report that gives a good sense of where these opps are coming from: moreDetailOnUnpubJobs.xlsx
Generated from:
select
u.first_name AS created_by_first_name,
u.last_name AS created_by_last_name,
sjo.created_date,
sjo.updated_date,
sjo.name,
e.name,
c.name
from salesforce_job_opp sjo
join users u on u.id = sjo.created_by
join employer e on sjo.employer_id = e.id
join country c on e.country_id = c.id
where published_date is null
and closed is false
and e.name not like 'Test Account';
They're mostly from Canada and Australia, which I would've predicted, since they're pretty strong on SF.
Also need to do a bit more investigation here, looking at some of these job opps, they do have child candidate opps that are being updated on the TC...
Ahhh, of course: you can create the job and that gives you the sub list, then you can move candidate opps forward without publishing the job, which you could update via SF. Perhaps a fix here is not to provide the lists until the job's been published. Will run that by the team.
With the removal of the scheduled call, jobs will stop moving forward.
John noted that the creation of the lists before publishing is quite deliberate and necessary: it gives the job creator the opportunity to muck around adding candidates, drafting JD etc before notifying everyone else.
Given that, we decided the final step is more operational: issue a general communique that jobs will no longer be auto-syncing from SF to the TC, and reach out individually to Yousef and Charlotte, and the Canada team who created many of these opps, to reiterate the importance of updating on the TC after publishing the job —framed, obviously, as a learning opportunity rather than some sort of rebuke.
To wrap this up, I've contacted Charlotte, Yousef and Saleem to ask if they could publish their jobs and update them from the TC from now on, also offering some time to talk through how it all works. I also have a reminder on the Ops Asana board to check that it's been done a couple weeks from now.
Discovered while John and I were in prod looking at something else https://tctalent.org/admin-portal/job/1116
It's not possible to change stage from TC while job is unpublished, so my hunch is that stages are being changed from SF and either copied to TC when job was created from SF link, or we still have some kind of sync running.