iCIMS Hacks: Understanding Integrations & Developer Tools

In this System Admin Insights session, Vivian Larsen breaks down the iCIMS Developer Site and the fundamentals of integrations. Learn the difference between REST APIs and flat file integrations, how events trigger integrations, and where admins can find key resources when vendors or IT teams start asking technical questions.

https://systemadmininsights.com/

Transcript

Alright. Let's go ahead and get started. Welcome, everybody, to
system admin insights, a community of highly creative ISIMS system
administrators.
And welcome to anybody who's joining us for the first
time today. Thanks for thanks for checking this out. We
are recording this session, and it will be posted to
the ISIMS channel here in Circle by Monday, so you
can go and check it out at any time. If
you can't attend 1 of our sessions, we have them
all archived
there. And, the audio from the session will be posted
to the SAI podcast, so you can also listen to
it there. Links are in the lower hand left hand
corner of the Circle platform.
We like to start out every session with a little
bit of gratitude
so you can open up the
chat. And
I am personally
very grateful for Caitlin Fale, who hasn't joined us yet,
but, I'll tell her again later. So Caitlyn is our
COO at IRD,
and Caitlyn has successfully transitioned us to a new
payroll and accounting provider. And as we all know, transitions
are a lot of work to do them right, and she has done an extraordinary job. So very grateful to
you, Caitlin, for that. Angela says grateful for warmer weather coming soon this spring.
Indeed. Indeed. Vivian is a among her many talents is she is
a, pro gardener. She is, has a very, very green thumb. Patrick says grateful for
our company TA manager who has great ideas and open
to suggestions. Being open to suggestions is key. That's wonderful.
Caitlin, hi. Volcano pedicures. You got the volcano pedicure?
Great. You deserve it. Craig says melting snow. Cordell says
yes. Marigold seeds in the ground last weekend. We are
all into plants. Love it. Okay.
So, before we get started, a quick reminder that if
you'd like to receive SHRM credit for attending the session today,
we will post the code as a comment on the
video by Monday. So just go to the ISIMS channel
and filter for recordings.
And a reminder that you submit that code to SHRM
directly to receive your credits.
Later this session, we're gonna be giving away a free paperback copy
of From 0 to ATS Hero, the Accidental Admin's Journey
written by our very own Vivian Larson. It is a,
it's really sort of like a there it is. There it is.
And and it it's the thing that I wish I
had when I did my first ISIMS implementation 10 years
ago. It goes through everything you possibly need to know.
And as a matter of fact, we are building a
certification course around it. So just teasing that a little bit. That is,
planned to be released at the beginning of May. We
will keep letting you know more about that as we
get closer to that date. But with that said, Vivian,
you have some stuff to share with us today for
another episode of now you know.
Yep. Okay. So we've been doing a series on the
developer site, and we've gotten through a couple of different
pieces of the developer site on the now you knows.
And for those of you that are just joining, now
you know is a session that we do where we
pick a topic that is items related, whether it's a
field based, like, how you can use certain fields in
the system or how you can use features of the
system. And then we just do, like, a little 15
minute mini tutorial on it. They're available under events.
I'm saying under courses as individual lessons. So if you
wanna go back and look at previous now you knows,
they're all available as part of the library to be
part of this community. But today is now you know,
we're gonna be continuing the series that we've been doing
on the ISIMS developer site. And the goal of covering
the developer site in such depth is giving everybody just
an idea of what's possible and where to start if something comes you across your
desk that is involving an integration. So we've already covered
a couple of different moving parts on the developer site. We've covered,
getting started. We've covered,
some of the different moving pieces associated with it. Let
me get sharing working here. Sharing is not cooperating.
Allow share window.
So just as I was saying, courses,
all of our past now, you know, is right in here. 
But for today, we're gonna continue covering the developer resources
site. So if you've not logged in here, you need a username and password. It
is not the same username and password as your ISM
username and password. So if you've not previously logged into the developer community,
I am going to drop the community
link into chat and then encourage everyone to go and,
create their profile in the developer community. There's a lot
of really good resources. If you look at the now
you know from about 4 weeks ago, I covered that
this is a good place to get to release notes
and some of the, up and coming
schedules for up and coming improvements in ISIM. So there's
a lot of really good there's a lot of meat
here. So I really recommend you spend some time deep
diving into this because you can find a lot of
good information about ISIMS that helps you inform some of
the decisions that you're making as far as needs that
are upcoming. But for today, we're gonna cover the applications
piece. And this is really we haven't touched on this
1 just yet. And the reason for that is it's it's meaty, and it locked me out.
Alright. So applicant this applications piece covers the 3 different kinds
of integrations that ISIMs allows.
They are applicant tracking. So with the core ATS,
offer management has its own set of integrations and onboarding.
Onboarding and offer management, they're very minimal. You see that
there's only 1 line next to each 1 because more
often than not, what is included in them is just
the documents themselves being able to extract them into an HRIS.
And so more often than not, onboarding and offer management.
Onboard does have a couple of bolt ons such as
I 9 integration and, I've seen WOTC
integrations with different providers and onboarding. Those are all covered
under the marketplace and vendor,
but onboarding by itself is typically just getting the finished
documents from ISIMS into a secondary system. So I'm not
gonna go into too much depth on these guys because
there's only 1 thing here and you're more than welcome
to go digging yourself. There's a lot of meat here,
so we're gonna spend most of our time here today.
So before you get too deeply, into these, I want you to understand
the core types of integrations that ISIMS I'm not saying
this is the only kinds of integrations, but the core
types of ISIMS integrations that ISIMS allows.
So there's 3 of them. And typically, the 2 of them that you are going to build
are either a rest API or an SFT flat p flat file.
In very rare instances, there's a streaming integration. There was
a feature called data stream that they were promoting around
20, so some of you may have it. It
has been being sundown. REST API is a kind of integration that you see when you
need more real time actions. So essentially, instead of waiting
on a schedule, which is what's the SFTP and flat
file are typically set up where you can set them
up every hour. SFTP flat file can be hourly. But
REST API is instantaneous.
So a user takes an action in the system,
and that action can be immediately sent to a secondary
system. So the biggest difference between REST API and flat
file,
is that REST API is typically
immediate. It can be real time,
and it reads and writes information. So REST API can
write information in the ISIMS platform, not just the secondary
platform that you're integrating with. Whereas SFTP
flat file can import information
into the ISIMS system, but not necessarily write to 1
specific field. So let me give you an example. If
you have a rest API integration within your offer details
tab, where you have a secondary payroll system that is
doing all of your payroll,
calculations
that writes back to the offer details tab what the
offer amount possibilities are.
I've seen these configured by trigger status, so you have
a status that says,
offer
approval or or basically creating offer. And that triggers an
integration out to the, payroll system that comes back into
offer management
and writes into offer management on the offer details tab,
the different pieces,
of potentially
offerable
information.
That would be a rest integration because you're writing direct
information into specific fields for 1 candidate
in real
time. Whereas an SFTP
flat file would be more like,
sending information out of the system
to export new hires
into your your HRIS
and then moving that information in the HRIS
to an employee profile and sending the data back into
ISIMS in a batch where there's 1 or 2 or
however many hires in a day to update the employee
tab with all of the relevant information associated with those
hires. So I'm gonna pause here. Any questions?
No? I think you had a metaphor once about,
the different types of APIs.
A REST API was kinda like a phone call
and another type. Do you remember that metaphor? It was
really good.
Not off the top of my head. I gotta work
on it. 1 was like texting, and 1 was like
a a phone call.
Right. Yeah. I actually think that was your metaphor.
Oh, okay. Great. Yeah. Phone call versus snail mail. Good
metaphor. Apparently, I've forgotten it. Alright. I'll work on that
1. Sorry.
That's fine.
So that's
rest API versus SFTP p flat file. Those are the
2 that you really do need to concern your softwares
because they're the ones that ISIMS is most likely to
use. There are a couple of different types of API
integrations out there. These are the only ones ISIMS really
does.
So
the next thing,
is the different methods.
So
in a REST API,
you're going to have conversations with folks who are starting
to do the integration,
and they're going to use terms like post, put, patch,
get, and delete.
These are all different actions
that take place in an API integration.
And so those actions, a get is a read or
retrieve of data. It pulls information
without changing anything. It is repeatable and safe.
A create
sends new data to create a record.
Each call creates a new entity. So a create would
be an instance where we were creating a job template
within ISIMS. You could do a create post,
if that was an API. Those those are typically flat
file. A put is a way to replace information that
is in a record when and you see this overwrites
entire record. What that means is the entire record that
it is being mapped to. So that could be the
entire record of data in 1 field. That doesn't mean
they're rewriting, overwriting an entire person profile.
Partial update is a patch. It means you're only updating
individual fields that you send. Everything else stays put.
A delete
removes
entire records.
So I have seen deletes written,
for folks that have
integrations
with their HRIS
where they have
basically sundowning rules.
So that's a database
maintenance piece, but I've seen some automations
around
companies not wanting to keep employee records beyond 5 to
years.
5 years is a little
early. 7 is is more common. 10 years is is
the long term.
And, essentially, the system just basically deletes all this kind
of integration deletes all employee records that are aged out
of a certain defined time frame so that you don't
have to sit in the ISIM system and manually remove
all of these different kinds of records
from the ISIM system over time.
So I've seen that kind of thing. I don't see
deletes written very often for any other reason.
Alright. So,
this little document is something that we're gonna share in
a post on circle after the call here for everyone
to take away. Going back here now that you understand
the basics of arrest versus a flat file, these are
the different things that you're gonna wanna really deep dive
into.
So the applicant tracking integrations that are available
are all
listed out on developer site.
And the data models are important for you to know
because
ISIMS has a very specific language.
And if you don't speak the same language as support,
it can very often be difficult for them to understand
what you're trying to ask for and
that somewhat syntax
translation error leads to a lot of frustration.
So if you say you wanna update a form, you
need an I form. And I know that miniature
change might not necessarily seem like a big thing to
you, but there are other kinds of forms in the
system. There are interview scheduler forms. There are,
forms. Some people actually call their offer details tab forms.
Some folks call the approval page forms. So you want
to try to be as specific to ISIM's language as
possible when interacting with the support desk,
because it will help you avoid some of those lost
in translation errors where you spend a little bit of
time trying to figure out what each other is asking
for. And so a clear definition of what a lot
of them are is right here.
An event,
for instance, in ISIMS
is any action that takes place. And so this clearly
outlines for you
all of the different kinds of events
that you could potentially integrate with. So if you see
a plus sign here on the right hand side on
the events tab, it basically explains all the different fields
that are individually
possible to integrate with. So for instance, this additional details
is not something that you could potentially integrate with, whereas
category
is something that you can integrate with. Each 1 of
these little values that is written here essentially means,
that there could potentially be information within category you could
integrate with. Here is a flat file type in this
case,
and each 1 of these individually outlines
what the potential output would be. So for instance, this
is a currency field, which is why you don't often
see a lot of information in it. And date,
not so if it says NA, it means that the
output of that information is not available
in this kind of a format. And so what essentially
these mean
is that this is a list single select list options
field type.
And that's a real important call out for me when
it comes to integrations.
If you are ever planning to integrate a drop down
menu
in the future,
don't use single select fields. Always use list options fields
because list options fields gives me a node ID for
each value,
which means that when I am doing an integration
with that particular field, I'm consistently writing the same value
over and over again and not creating
additional noise in your system. So in the single select
fields,
I can't
for instance, if I would want to write this category
this is a bad example. But if I would want
to write this category from a secondary system into ISIMS,
if it were just a single select field, I could
not send this particular
career value dataset.
I could send career value as a text value,
and potentially, that's where you get a lot of places
where you're creating multiple of the same values in a
system.
Whereas with a list node,
I can send this list node, and it will know
to match it to the career fair value that's already
in that list node.
So I wish we could hide the single select options
type. Everything should be a list node for the sake
of future integrations in my personal opinion. Can we shut
up any questions? Yeah. Let me jump in with a
question. So,
what sort of customers are
who is this most appropriate for?
Right?
Because some customers are gonna want to offload this and
have somebody else do it. Some customers are gonna really
respond to this level of visibility and granularity in terms
of what you can access just through the developer site.
Is there an inflection point where you feel like it's
really appropriate for a customer to be in here and
and and doing this sort of work in terms of
company size or or maturity?
Anyone who ever has any intention of building any kind
of integration
should be familiar with this site. Okay. It's not a
size.
It's not a,
complexity.
Now the level of depth that you are gonna go
into this, reading every single 1 of these, understanding all
of the different call types.
No. Don't spend your time doing that unless you have
a real reason to know. Know where you can get
to the information Yeah. Here.
Know how to get to the information.
Be familiar with navigating it, but you don't necessarily need
to read every single 1 of these. What's more important
to smaller customers
is this developer marketplace where you can see the different
kinds of integrations.
And then once you've decided what kind of integration you
want, which is what we covered last time. So for
instance, background screen,
the different kinds of partners, background background check integrations that
are available there.
That is something that you
this isn't the same as ISIM's marketplace where it tells
you all of the different vendors Yeah. Who are available.
This is ISIM's basically, like, the
the particular types of integrations
and how they would individually map them. Why is that
not cooperating?
Sorry. I'm good. I'm driving everybody crazy. I'm gonna stop
making everyone nauseous and go back to this 1.
So it just doesn't wanna show that, I'm trying to
click on it, and it doesn't wanna show it. Anyway,
so the customer this is not necessarily a customer size
or or breakpoint type of question. It's more
has have you been tapped or asked to do any
kind of integration?
And if you have,
it's important that you understand where to find the information
for your vendor Got it. When your vendor's starting to
ask questions about what kind of integrations they could do
Got it. And what's available. That makes sense. Peter had
a question. He said you're talking about field types. Right?
I'm not sure. Yeah. In this case, yeah.
In this case, I'm talking about field types. So you're
saying that to it's better to do drop down single
select versus single select list options.
No. I'm saying the latter, the opposite. It's better to
do list options.
Right. Right. Yeah. Okay. Okay. I I put in the
screenshot in the chat.
Okay.
Okay. Yeah. That's helpful.
Okay.
So I've taken up about 20 minutes of our call
here today. I don't wanna bore everybody with going through
each and every individual 1 of these. The only thing
that you wanna call out here,
is the concept of an event is an important thing
when it comes to any kind of integration in the
sense that an event is an action that is taking
place on the ISIMS side.
So an event is moving the status to a workflow.
An event is
changing the values in a field.
An event is creating
a job or creating a profile.
So as far as ISIMS is concerned, there's only certain
types of event types,
that are available for integration. And that's
if you look at event notifications,
this is more familiar this would be something that's more
familiar
to everyone
here.
These are all of the types of actions that can
trigger an integration
event.
So if I am looking so the event data model
is field based information.
The event notification
data model is action
based information.
So the difference between these 2 is I've changed the
values in a field, and I want to call that
field or send that field out by a flat file
or API.
An event notification is I have the candidate has completed
their application. Someone has edited the job. Someone has posted
the job. The job has been unposted.
Someone has completed an onboarding portal task or someone has
updated a workflow status. And in all of those cases,
I can trigger an integration off of any 1 of
these events
in the system. So a lot of your integrations themselves
are built based on events, and that's 1 of the
reasons why they won't open event notifications up to general
admin
because it is a place that they can't segregate,
between the ones that are you facing, customer admin facing,
and back end facing as far as building and modifying
existing integrations. So it would be very easy to break
existing integrations if people had access to this area of
the system.
So
that's about as deep as I wanna go for today.
Does anybody have any more questions about developer site or
any questions about different types of models of integrations?
No? Or any issues that have come up with integrations
recently?
Mhmm.
I
have Go on once. Question. It's a little bit general,
but
I have 2 different pending
API
connector integrations.
And the project manager from ISIMS reached out, to us
ahead of time with a bunch of questions that I
don't know how to answer.
Basically,
just as a part of the kickoff.
And I'm gonna see if I can find them quickly.
But I guess the biggest question is where do I
go to find this information? Because when I talk to
my account manager about
the questions
I'm sorry. I'm trying to pull it up so that
I can reference it. I didn't quite
have it ready. Okay. Actually, I do have the questions.
Like, so we talked to our account manager. We understood
on a high level, like, what was possible with the
integration. We requested it. We get in the queue for
the kickoff, but we don't really know what it is
because we haven't talked to anybody about it. And so
then suddenly they're asking you very specific questions. Like, if
this is a non custom integration, do you have an
understanding of how it'll function?
If the connector has any customization
involved, is the third party vendor prepared to flex to
support?
You know, are any API credentials necessary to be granted
for now or in the in the future? And I'm
like, I don't know the answer to any of this
because nobody has spoken to me about what's even possible
with this integration.
So it makes me nervous that when we get on
the call, we're not gonna be able to fully leverage
everything. And I think I need to come in with
some research prepared so I can kinda speak to what's
possible because I feel like otherwise they're just gonna steer
me in a very basic direction.
So
I'm gonna vent a little bit here. In
years working at ISIMS, this was a constant
friction point
both in implementation and in the integration team. The integration
team's trained, and their mindset is
the customer knows what they want, and they should come
to us already knowing what they want. It is not
our our our place to consult
or advise.
And you are literally describing why this is a constant
pain point, and they've never fixed it.
So that's my little mini rant.
Now to answer your question,
yes. The developer site is a good place to start,
but it's overwhelming. There's a lot of information here. You
don't even know what to look for initially, and I
get that.
The thing that I would
let's let's
use your case as an exercise here. Everybody here needs
to learn these things.
Tell us what their questions were, and maybe we can
work through them.
Sure. Do you feel comfortable doing that? Them in the
chat if you like. It's the,
if that's the easiest. And I they just we have
2 different ones pending, and they sent the exact same
questions for both, even though they're different. So I I
get the feeling that it is always
questions. Yeah. It's it's a form letter, basically.
Okay. So this is a non custom integration. Do you
have a clear understanding of how the integration will function?
What do you expect the connector to do? First off,
what type of connector is it? Sure. So I believe
that they're both APIs. 1 of them is for Qualify.
Okay. And I understand on a high level how that's
supposed to work. The other 1 is the UKG.
It's their latest version, and I'm just going and looking
because I put the exact name of what it is
in here recently in Circle.
Let me see.
So I'm just looking for
Version 3. Is. Yeah.
So those are the 2 that we're gonna be working
on.
Okay.
So the specifics
of version 3 I've actually been reaching out to an
ISM team member former ISM team member trying to, get
some details on version 3. I don't really have good
ones.
The specifics of version 3, I can't answer. What I
can answer is if it is a version, it's standard.
So standard meaning they have a preconfigured
set of integrated
values that they are able to work within. So the
answer to question 1 for the UKG 1 is it's
a standard integration. It is non custom.
And Got it. So the question, do you have a
clear understanding of how the integration functions,
is more a question around mapping.
And what I mean by mapping is they wanna understand
if you have taken a look
at both systems
and looked to see if the fields on 1 system
can be directly translated
into the fields in the other system.
So I'm doing a project for a Dayforce mapping with
a customer right now, and
the whole majority of the conversation is, well, we call
the field type, but in day force, it's called pay
class.
And so there's a translation that needs to happen. Thank
you, Angie. She just dropped me off. Looking at that
1, Angie or Angela. Thank you. Yep.
So so, basically,
they're looking to see if the if you understand
what data translates
in your system, in ISIMS,
to what data trans in in a the source system.
System. Like, do you know what is going to map
to what? Mhmm. You might call it in type you
might call it type in ICIMS, but it's called pay
class in your HCM. So that kind
of flow mapping is something that I always recommend everyone
start as an exercise
before you start an integration.
Look at where your your direct correlations are. So let's
move on to the next 1. If a connector has
some amount of customization
involved, is the third party vendor prepared to flex. So
where this custom where this question is coming from
is when it comes to standard integrations, very often the
vendor is not gonna assign you a a resource that
is capable of doing custom mapping.
The vendor is very often gonna assign a resource that
can simply check boxes essentially on the back end.
Whereas the vendors themselves
very often actually need to write code if there are
customizations,
and that's a different tier or level of resource.
So
have the conversation with your vendor
if you think there are any customizations that are gonna
be unique to you. So for instance,
there's a different way that you manage
background checks in your system than the standard way that
background checks are managed, and you're gonna need all custom
fields. Well, now you need the vendor to know that
they're calling custom endpoints that don't exist in every ISIM
system. They only exist in yours. Does that make sense?
Mhmm. Yes. Yeah.
If there's an SOW signed so I wish I had
a dollar for every time I got a customer who's
like, yes. We're integrating with HireRight, but they haven't finished
negotiating with HireRight.
And so they want me to start building something when
the vendor hasn't even finished negotiating the rate or signed
the SoW, and you don't have a resource.
Where this is coming from is license has really long
queue for integration resources,
and they don't really have the time to wait
for you to figure out your SOW situation with your
customer. So they're requiring that you have your SOW finished
and signed before they'll actually start assigning a resource.
So that's that's something to be very clear about.
Do we need to have a scope of work signed
with UKG if we're not requiring anything
custom from them?
As long as your admin is able to do the
work themselves,
no.
But you need to give them the answer for number
3 that it's not required because your admin has the
ability to do the work.
Got it. Very often, though, if it's vendor to vendor,
like a background vendor or someone else,
you or an assessment vendor, you should have an SOW
just so it's clear what the vendor's expectations of the
interaction should be. You are the traffic cop between ISIMS
and your vendor, and your vendor needs to clearly understand
what you need so that they can advocate with ISIMS
to keep you
in mind when they're doing their work.
Okay.
K?
Do you have a confirmed vendor contact?
Again, if I had a dollar for the number of
times I had an integration start and they didn't even
know who to call at their vendor,
I'd be rich late. So this this is a selfish
question on ISM's part to ask, but it's valid because
very often,
the TA person isn't the person that's been negotiating this
procurement of this new vendor.
And that conversation has been happening with a procurement person
or a leader.
And the person who's actually doing the implementation
hasn't been given the point of contact at the vendor.
It's a breakdown of communication we see over and over
and over again. That's why they're asking.
Do you have an internal development resource ready if available?
This question is loaded. This question is only really relevant
if you're building any kind of API with a middleware.
Okay. So if you have a middleware involved, you definitely
need a belt a developer resource
just to be able to ask questions and do some
mapping.
If you don't have a middleware that you're working with,
the vendor should be enough.
But if you run into any issues as far as,
firewall and and that type of thing within your organization,
just having an IT contact here should be enough. So
I would say yes to this question if you know
who you can run to, if you run into a
technical issue in your organization.
And then finally, are API credentials necessary to be granted
for now, for what purpose, and do you need to
perform IP white listing to successfully connect?
If you're definitely building an API
integration,
yes, you need API credentials.
If you are not building, if you think you're gonna
be gonna be building a flat file, you don't need
API credentials.
But the integration itself, if it's an existing integration you're
modifying, you already have credentials.
So all you need to do is make sure that
the endpoint that you're sending your information to has those
credentials
and can call the ISIM system.
If How do we it is. Good.
How do we know if we already
like, for us, we do, I think, have a flat
file or something in this case, and we're just updating
the integration.
How do I know what those are and where to
find them? If it's flat file, you don't need API
credentials.
Okay. I think we're moving maybe from flat file to
API. Then you will need them to generate them for
you.
Okay.
So and you will need to do something in the
endpoint system or your ACM or what or UKG,
to grant them
the access on the API through API calls on the
UKG side. They actually should have a ISIMs. Your integration
specialist, when you start working with them, should have a
spec notification
of all of the different pieces that you will need
to do steps that you will need to do to
map it on the vendor side,
on the UKG side.
And
they're pretty easy to follow. I actually just went through
them with another customer this week.
So
overall,
if you're building an API integration and you know your
flat file, yes, you need API credentials,
is the answer to this question. Do you need to
perform IP white listing to successfully connect? It's always a
good idea.
If your IT team has not white listed everything that's
up on the community site for white listing IP addresses,
which changes occasionally and did change sometime mid last year,
then you should definitely be reaching out to your IT
team to do a white list in order to make
sure that there are no stocks
between the 2 systems. Peter, you're nodding your head.
Yep. Okay. Alright. Thank you, Jessica, for those questions. Oh,
very helpful. Thank you. Yeah. And thank you, Vivian, so
much for
talking us through the developer site. If you have a
special request
for Vivian, let me share my screen here.
Alright. We're here in the platform.
Under now you know request,
we're doing 1 or 2 of these a month. So
if there's some special topic that you would like for
Vivian to cover, please click that link and fill out
that form.
Also,
our coming events are over here. We are doing a
LinkedIn live. It'll be me and Vivian
talking through
subject material from her book. Vivian, what are we covering
on Monday?
We are covering chapter 2. So we're gonna be covering
all of the
various
moving pieces like the 4 piece of
the beginnings of
looking and setting up a system and understanding all of
the different moving parts, process, people, etcetera.
Great. That'll be Monday at 12 o'clock eastern.
And now it's time to spin the wheel of fun.
Caitlin, are you ready? We're gonna give away a free
paperback copy
of From 0 to ATS Hero, the Accidental Admin's Journey.
Oh, is it Cathy or is it Lauren? So close.
It's Cathy.
Alright.
Cathy Nava, congratulations.
Please DM
or email your mailing address
to Vivian, and she will send you a copy ASAP.
Congratulations. Oh, well. Thank you.
Our pleasure.
With that, let's move on over to our
general questions.
I'll hop back over here,
and we go to the ISIMS channel,
and we click live call questions.
And, Jessica, I'm gonna open up the floor before going
to this question. Is this question something that we already
talked about?
This question is exactly what we were just talking about,
and I'm connecting with Jen and Angela via chat on
it. Wonderful. So glad to hear it. Alright. Thank you.
So the floor is open. Who else has a question
today? No question too big or small.
If you're new to the group, don't feel like we
went really deep on integrations today, but we talk about
everything here. So you're welcome to bring anything you like
to the group.
Greg Mendez has his hand up. Greg, what's going on?
Hey. It's Greg from NYU. So I I was having
a bit of a debate with ISIM support. We're actually
gonna have a bit more of the debate,
right after this meeting.
So it's the infamous question,
first in versus last in. Mhmm.
So here's the scenario.
Trying to do an event notification,
and, of course, as event notifications
work,
it's we're gonna base it on a status. So person
a person a is placed under status x, and then
something happens. In this case, an email.
So pretty
but I know this type of status, I know that,
people are gonna put them on are gonna put them
under multi the status multiple times by accident. There are
lots of ways this can happen. We've been asked by
our lawyers, hey. We need to make sure this they're
only placed under,
that if it's they're put multiple times in the status
by accident or for whatever reason, they only receive the
notice once.
And so my instinct was to put it under first
in. So first in that status,
then that way, if Greg, you know, if Greg applicant
gets, you know, put under that status
several more times, doesn't matter. Greg applicant won't be bothered
with another email notification.
I assume so differently. They were like, no. No. It's
last in. And I just felt like last in
is counterintuitive.
And I figured, let me bring out to the brain
trust here and say,
is it first in? Is it last in?
Is there, you know,
is it counterintuitive and it just
works
that
way?
So it
it really does depend on the type
of action that you're taking. Can you give me a
bit more granular information?
Like, where where are you acting?
So this would happen under the recruiting workflow. So I
have a a job.
A purse we have an we have an applicant stat
there's a status.
It's called, blah blah blah,
meets minimum qualifications. So a purse a human being has
reviewed
a union member,
then they're going to they'll
put this union member under the status, under the job.
Once that's once the person's placed in that status, the
event notification
will be triggered and will send out an email from
our email template library.
The first time is just fine, but let's say that
I don't know. I I continue dispositioning this person
for the next few weeks, and then I forget. And
I put the person back, and I go ahead and
I I put, the applicant again under the same initial
needs to be on qualification
status.
It will re trigger the event notification. Hey, Mitrice. We
wanna so our our lawyers are like, we don't wanna
bother. We also wanna cap it. So we intentionally wanna
have it so that look. If if that gets picked
up by the filter,
great. But
if you were to well, we wanna keep that email
from going out more than once. I know Isom said
there's no, like,
counter or feature within event notifications to say
this person was already sent the email. So that's when
we started saying, okay. Well, we know once the person's
placed under that status when they were placed.
And
if we did either something like first in or not
yeah. So, like, first in, then we could be like,
that would act like gate. The engineers are like, no.
That that's not gonna do what you think it's gonna
do. Mm-mm. They're right.
It's not gonna do what you're gonna think it's gonna
do. It's gonna continue to send it. We ran into
this a lot with a big client of mine who
you get when you go to drive rideshare.
So I won't share their name. But, essentially,
they were trying to do something very similar to what
you're trying to do, and it did not work.
And the main reason is that any any time you
take an action
in ISIMS,
it is an event, and that is how events are
set up.
So there is no way to apply a condition
to an event
triggering action.
I can't say it is an event only if it
has not been done previously.
So
for the sake of event notifications,
I don't think what you're asking for is going to
work.
The only thing I could potentially recommend is that you
set up entrance criteria on the specific steps
triggering your event notification
to not allow someone to be moved back into that
status.
Okay.
Yeah. Okay.
So, basically,
if we can't stop the note so you're saying is
the we can we can put entrance criteria to stop
the person we were put there. So,
I guess I would have to put a entrance criteria
on the status itself, something like
if if you've ever been like, if any,
then
in this status, don't allow the person to put them
back in. Correct.
Ever in any? Ever in any. Yeah. And so that
it's kinda reflecting on itself. And it was like, well,
I you have been, then I can't put you I
can let you go back in.
But just so I have a better idea,
I know ISIMS wants to use Lastin, and I thought
Lastin was
pretty much that it gives it's it's that's we use
it for integrations because we do want when we do
integrations, we do want the the latest time that someone
got put in.
So what is the purpose in first in then?
I'm drawing a blanket how to answer that question.
The what is the purpose of first in versus last
in? Yeah. Like,
So if I were doing a report, first in would
be I wanna know when someone was first moved to
the status for the sake of calculating, like, time
of action, essentially.
Last in is if you're looking from a projections
perspective
at how long it has taken from someone
to from being in that status
to the next status, essentially.
When were they last in status x
and moved to status y
is a last in.
Yeah. So first in is kind of like a creation
log. Yeah. In a sense. Yeah. That's how I've always
used it. And so and the reason we can't use
it in this case for event notifications
is that
event notifications if I did, like, first in status x,
the event notifications
is
not looking at that kinda like what what Alex was
saying, looking at it as a creation,
log
and
is disregarding it or not treating it like we would
want we would expect. So it's so if it if
it says first entry under status, let's say, yesterday,
it's not the event notification is not gonna recognize that
that person was placed under that status yesterday. It's just
gonna it's because it's
looking at it not from the status perspective. It's looking
at the at from the perspective of an event. The
event has not yet happened,
The current event.
Okay.
Yeah.
Yeah. Event notifications
are point in time.
They take place
immediately at first their first end. That's how they're set
up. So there are no conditions that you can apply
to event notifications. They're just the second the action happens,
the event has happened, and that's the trigger. Okay.
Alright. Thank you. Thanks for the question, Greg. Thank you.
Who else has a question today?
Christine? I
Oh, somebody has a question. Yep.
Go ahead. Peter, no. Go ahead.
So we have
a fun conversation
with with our,
account rep for,
disposition codes.
Right now, we're writing dispositions
using notes.
I'm sure you're aware of this, Vivian.
And and there,
the options they're giving us is to do a multi
status, multi bin
solution,
but that would mean create for us to create 40
different statuses
because
there there's,
not selected,
during the interview. There's not selected
during the offer, and there's a hiring manager. Hiring managers
can
select not selected. Recruiters can do not selected, which equates
to 40 different statuses.
So we can't do that. And, the second option is
doing an action where it the an iForm
is
pops up, and you put the this position code there
for not selected.
I haven't seen it done. We're asking them to show
us a demo.
Maybe we can do it on our staging site, but
it just seems clunky to me.
The main goal is for reporting.
We wanna
we wanna
be able to
report on why
recruiters and hiring managers are not selecting candidates.
What is your
suggestion on this? Because I don't think ISIM does a
good way in capturing that data or an easy way
to capture that data.
So there's there's a couple of different philosophies around disposition
codes, ISIMS specifically.
And dispositioning
in the individual bin
using a status
is really the ideal
way for reporting.
I know you're gonna hate this.
For reporting purposes, having a status
dispositioned
and let me take that step back. So if you
are going to have the disposition stat I always would
build them where there was a disposition bin and all
the disposition statuses were in 1 place because
when you're scrolling through all of your available statuses, it's
a lot neater
to do it that way.
But the disposition statuses that are in ISIMS, the way
that the native disposition functionality
works, you can't hide it from individuals.
And folks that have the ability to see the individual
dispositions in that that area of the system,
there it can't you can't drive the experience using any
form of entrance criteria.
They just see all of the options, and they can
pick whatever option
option and say whatever they want to
if you leave the add note on. Okay. Whereas with
the
statuses, 1 of the reasons the statuses are a preferable
way to go is you can configure a per disposition
email
and send a specific notification
out as part of the disposition.
That way, you can't do that in the standard disposition.
I
I never
thought of it that way. Yep. And then the other
other thing is you can't double if you set up
entrance criteria properly, you can't quadruple or double disposition somebody.
You basically can say if the person from an entrance
criteria perspective is in this disposition status, don't disposition them
again or move them,
out of this disposition status. So
reporting wise, it is much easier to report
on them.
Jessica, you have something to say about this, though. How
do you guys do it? Yeah. So we actually did
an overhaul of all of our bins and statuses last
year for this exact purpose, and I kind of mapped
it all out in Excel. So I'd be happy to
share some information Yeah. That would be amazing. Up. But
what we did was we didn't wanna have, like, 1
bin for dispositions because we wanted to be able to
visually look at the job and see
what stage did they make it to. So is it
new submissions,
screen, interview,
hired, offer? And then we have kind of all of
the same rejection reasons within each of those bins. So
we could visually look at it or report to say,
this man, they made it to the screen stage, and
they were either advanced or rejected. So you can very
easily visually see and report on what stage did they
make it to and why were they rejected within that
stage. And then we tied specific email templates to
all of those so that we're giving those more customized
reasons when we're rejecting cases.
And it makes it so much easier than trying to
sift through everything. So we really love have loved the
change. How but how many
statuses do you have per bid?
I have to off the top of my head, I
can't tell you. I can go look at a job
right now.
I have the document.
I will say, like, most of the time, we are
having to expand to 2 pages of the people tab
because it looks a little bit longer.
But it's it's really not bad.
The I form option is an option sorry, Jessica. Go
ahead. No. Sorry. That's it. I was gonna say the
I form option, I've never seen anybody do.
It is an option. I could see why they're recommending
that you do that, but reporting on that is gonna
be a beast. Yeah.
Sorry. 1 other thing I thought of. The other benefit
to the approach that we took is we do high
volume recruiting for hourly positions mostly. So we get a
lot of duplicate
candidates.
And what's really great is that you can put that
recruiting workflow history icon on the people tab in the
search results,
and then we actually can click very easily and see
the exact status and reason they were rejected or where
they made it to when they're applying again, which was
really nice. We also can go back if you ever
wanna, like, reengage
or do, like, bulk outreach based off of the status
and the stage that they made it into. We liked
that we had that option in visibility.
So lots of benefits for us.
But how many disposition
options do you have?
Like, for example, you have 5. Do you let's say
you have 10.
Do you replicate all those in the different bins that
you have?
Most of them are replicated. Some are not depending upon
what sheet it's at. So, like, for us,
our different reasons and here, I'm just pulling 1 up
because I don't have the exact list. I'm looking at
our platform.
Okay. So we have here are the different bins that
we have. We have,
not considered, which if you're are you a contractor with
OFCCP,
a government contractor, or no?
No. Okay. Well, then your life's gonna be a lot
simpler for you.
But
we set ours up with that in mind, and then
our situation changed so we don't have to be as
stringent now because we no longer have some of the
same contracts. But regardless, we have a bin for not
considered,
which is more like position put on hold. They were
never reviewed or a late applicant. They weren't eligible for
rehire. There was a work authorization or a visa issue
requirement. So we have the not considered BIN, which basically
means we don't you don't have to count them in
AAP reporting is a very simplified way of saying that.
Then there's initial HR review, initial hiring manager review because
you for reporting reasons, you kinda wanna know
who what what it was reviewing them.
We have the screen bin, the interview bin. And so
in the screen bin or an initial review, we have
things like,
they lacked the minimum qualifications
or they were not the best qualified, and then we
have different reasons. So we either have experience, education, skills,
or other,
or they were not selected for job fit or career
goals were misaligned
or interview responses, you know, different reasons. And then at
the interview stage, or I think it's a certain stage
we didn't really have that they lacked the minimum qualifications
because by the time they made it to that stage,
we already knew they had minimum qualifications. It was just
that often that they were not the best qualified.
But, again, I I do have this all in an
Excel document, and I'm happy to, like, send some screenshots
if anybody is Yeah. That would I'll I'll reach out.
I'll I'll find you somewhere. Yeah. I'm in circle.
And if not, I I'll drop my LinkedIn,
handle in the chat as well. That'd be awesome.
Thank you so much. Thanks for the question.
Christine, I was wondering if you had any questions today.
What brought you to the call?
Yeah. Are you asking me? Oh, I was asking Christine
Dornbusch. Oh, okay. Thank you. The first session. Sorry, Christine.
No worries. Detail.
To Christines.
I'm just trying to absorb
any and all information like a sponge.
I have
completed the system user
certification through ISIMS, but my organization will not
give me
that level of access.
Ah, interesting. So I have to,
like, basically know what to ask for from our HRIS
system, like, system admins who don't work in the talent
acquisition team. Mhmm. If that makes sense, I'm on the
talent acquisition team. And so
if I don't expose myself to what's capable within the
system, it's just never gonna happen. And I can't actually
poke around
in our tool because I don't have the system configuration
tab.
So I
learn by forums,
like, on ISIMS community
and
webinars like this.
I actually probably have a question that's easy to answer.
Jessica mentioned it.
What is the best way
that I can see recruiting workflow history
for a per a specific candidate
without having to go into the job?
Like, from their
from their person profile, do I have to, like, ask
for that icon to be added? That's, like, my biggest
pain point right now.
Yep. So said
ask for the recruiting workflow history icon.
There's a little icon. I think it looks like a
document.
If they add that to the output, you'll be able
to click on that and see recruiting workflow history. Is
that what you're asking?
I don't know. Because I missed some of those words
don't mean anything to me. Got it. Got it. Yeah.
This I mean, it's a tricky trick tricky situation. Jessica
had a great, suggestion. She said, ask if they'll consider
giving you limited admin access,
which is possible. And, Vivian, we were just talking about
this yesterday.
It is possible to get Vivian, can you say a
little bit more about what that looks like? So, essentially,
limited admin access gives you the ability
to see everything but the system configuration
tab. So you could create your own scheduled reports. You
could
manage dashboards because I'm sure nobody on the IT side
is rewriting dashboards for you.
You could do minor tweaks like this specific tweak that
we're asking about is the modification of the output of
a report. It's not a system configuration in the sake
of adding fields or removing fields. So, essentially, it's a
limited access with that system configuration only turned off, but
everything else turned on.
It would give you the ability to create,
reports. It would be give you the ability to create
email templates,
stuff that IT is not gonna be
interested in doing for you as an end user of
the system. So you can make a case to them
that this is just normal system use for you to
do your daily job
and having to ask them slows you down.
I have some of that.
I can create reports. I cannot schedule them, and I
cannot manage dashboards.
Just take a look at the chat. Everybody is hopefully
giving you some suggestions here,
and I agree with all of them. And then, Kathy,
you have something to add.
Just, and I don't know if this was just covered,
but what if you give someone limited admin access and
you mentioned that okay. So sys config is removed and
they but they can adjust
reports.
If we have executive reports
and
we don't want anyone adjusting those, I guess that would
still give that person with limited access the ability to
adjust it because it's it's a report?
If the individual report itself is not given edit delete
access, no.
So in the config you know how when you create
a report, it gives it has those 2 checkboxes? Mhmm.
Can see, can edit. Just don't check can edit, and
it would even lock somebody in this route out. Oh,
good. Good to know. I okay. Because the limited when
we say, like, you're a limited system admin user, it's
a user group that you're put in, and they're setting
the limitations. So, like, for my group, we it we
have a child group of user admin,
and I named it limited user, and I just cut
off access to the things that I don't want them
to have access to.
And, Kathy, in terms of reporting, you can also,
have them remove the ability to overwrite globally.
So that way, they can't change anybody else's. They can
only change their own reports.
Gotcha. Okay. That helps. Thank you.
Peter, you dropped a nice screenshot in there. You wanna
talk through, what you shared there?
And if you gotta go, I just realized we're running
up on time. But, Peter, real quick, why don't you
talk about that? Yeah. That that's just the workflow tab.
Yeah. And at the end, we have the at the
end, we have the recruiting
workflow icon. And then when you click on that, it
gives you the second screenshot. That's exactly what I wanted.
I could I could only find that little folder icon
if I went to
the job for some reason and then looked at the
candidate list view. So that's exactly what I needed. Thank
you. New items,
you can do that too, but you can add it.
But you're gonna you're gonna have to make, you know,
for other people, you're probably gonna have to tell them
to look for that and add it. We have new
ISIMs that I can see it. Oh, okay. Okay.
Alright. Well, thank you so much for the question. Kathy,
you had another question there. Vivian, can you stay on
for another 5 minutes?
Yes. I'm not really as familiar with interview scheduler as
the rest of the folks on the call, though. So
we're still in touch. You. Have you touched interview scheduler
in a minute?
Little bit. Little bit. Yeah. Well, if you wanna stay
on and talk about interview scheduler with with me and
Kathy, feel free. Otherwise, we're gonna wrap up for today.
If you're interested in full SAI membership, there is a
link in the lower left hand corner called apply for
membership, and we'll reach out to you. Thank Thank you
everybody for joining us today. We're here every Friday at
1 30 PM eastern. Hope you have a restful and
restorative weekend. Thank you so much. Take care. Thank you.
Alright. So, Kathy, you have a question about interview schedule.
We are still in the implementation stage, and the question
came up if we could set everyone's availability preference to
8 to 5.
We know we can do this manually. We're hoping if
there's a way to set up for everyone across the
board.
Oh, so you wanna bulk update everyone's availability.
Right. Because we know it's like it's a 1 and
done. Like, use it's a 1 time availability preference, and
then that's it.
And Yeah. You know, I don't know. It it's it
would be so hard if we had to do it
manually for every single 1. We have, like, 700 plus
hiring managers. And to get them on board manually just
would not make sense. So we're hoping if there was
if anybody knew there was a way
an easier way just to do, like, a bulk
setting
update. It's a good question. Any thoughts? Did you do
the Microsoft
integration?
What do you mean?
So did you get were you able to get your
IT team to agree to let
the scheduler look at calendars?
Yes. Yes. Yes. Okay. So that's the first hurdle. The
second is,
are they all in the same time zone, or are
they all over the place? Global. So I know time
zones were a really big issue in the early days
of interview scheduling. I know they worked some of that
out, but I'm not entirely sure where that stands currently.
But I don't know.
I'm stumped. So, Kathy, I'm gonna throw your post up
into circle,
your question up into circle because I don't think anybody
here is confidently
able to answer your question. Mhmm.
So, hopefully, we can ping the greater group. I personally
have not touched interview schedule in quite some time, so
I wouldn't be able to answer this confidently.
Okay. Okay. Yeah. I appreciate it. We did for we
did it for our implementation.
We,
for we we
use Google Calendars,
but it was too long ago when I implemented it.
And I know we set it up for 8 to
5. Sorry. Yeah. Okay. Okay. So part of the question, Cathy, was,
like, if you can redo it after having set it
up the initial time. Right? Well, no. Well, we haven't
there's a lot of people that we don't even have
it set up yet. It's because we're still in the
implemented
implementation phase. So, yeah, if we could set have it
set up or turn on 8 to 5 for everyone,
then that would you know, that's what we're trying to
do instead of manually because it would be a lot
to do manually.
Vivian, if if she referenced Peter's
site, do you think it would be useful for,
tech support answering that question? Like, saying, hey. We know
that that was set up in in this other company
site, or is that asking for trouble?
No.
Sometimes it's a it's a good thing to actually be
able to mention another specific customer that has something set
up in a certain way if you have that knowledge.
It can give the help desk person a a trail
to go investigate.
But
if you're not 100 percent positive what that other customer
has specifically
done or configurations,
you're now asking them to trace down something in 2
different systems. So it's just doubling their work. So if
you're positive, you know exactly what that other customer has
done and you can point to it directly and give
them screenshots and examples,
great. But if not,
you might be better off just to start fresh. Okay.
So we'll post it up in circle and see if
anybody chimes in. Okay. Thanks, everybody. Have a great weekend.
I appreciate it. Thank you so much. Talk to you
soon. Okay. Bye. Bye now.