►
From YouTube: Support Ops - Zendesk - ZD US Federal-SFDC Sync
Description
Jason Colyer, Support Operations Manager, takes us through how the ZD-SFDC sync works
A
A
All
right,
so
this
is
the
repo
where
it
lives.
It's
currently
in
the
ops
instance,
there's
some
work,
we're
doing
to
kind
of
get
this
mirrored
over
to
the
main
instance,
at
least
just
as
a
display
method,
but
yeah.
I
figured
I'd
kind
of
just
get
started.
We've
got
the
redmi
file,
which
kind
of
goes
over.
You
know
some
of
the
required
gems
and
the
file
tree
and
the
sl
ql
that's
used,
but
we'll
go
over
that
as
we
go
through
the
actual
scripting.
A
The
main
way
that
this
works
is
through
gitlab
ci,
cd
schedules
for
the
u.s
federal
instance.
We've
got
four
stages,
which
is
to
gather
data,
compare
the
data,
sync,
the
orgs
and
sync
the
users
our
before
script.
We
have
it
echo
out
the
or
print
out
the
ruby
version,
that's
just
for
debugging
purposes.
In
case
we
have
to
look
at
you
know,
issues
when
it
fails.
A
We
haven't
installed
the
bundler
gym
and
then
runs
bundle.
That's
going
to
use
the
gem
file
in
the
repo
to
actually
install
our
required
gems.
A
Our
gather
stage
actually
consists
of
four
different
jobs,
which
is
the
precinct
zd
org
report
precinct
sf
org
report
precinct
cd
user
report
and
the
presync
sf
user
report-
I'm
not
very
original
on
naming,
but
basically
this
is
just
running
a
script.
You
gather
like
the
zendesk
organization.
Salesforce
accounts,
sorry
about
that
get
my
microphone
back
up
here.
A
Cool
yeah
but
precinct
sf
org
report,
which
gathers
the
salesforce
accounts,
the
precinct
cd
user
report,
which
gathers
zendesk
users
and
then
the
pre-sync
sf
user
report,
which
gathers
the
salesforce
contacts.
A
Those
these
will
generate
various
artifact
files.
The
org
report
makes
the
zendesk
orgs.json.
The
users
makes
the
zendesk
users.json.
The
salesforce
ones
will
make
a
salesforce
account.
Salesforce
users
or
contacts,
sorry
and
it'll
also
print
out
a
json
file
with
all
the
problems
it
found
during
sync,
which
we'll
cover
when
we
go
over
the
actual
scripting
the
comparison,
it's
basically
going
to
just
require
the
job
so
for
the
org
comparison,
it
requires
that
precinct,
zendesk
org
report
and
the
precinct
sf
org
report
it'll
run
the
compare
script
and
then
create
it.
A
A
All
right,
real,
quick
rather
james,
can
y'all
still
hear
me
all
right.
A
Yes,
sir,
all
right
cool,
sorry
about
that
microphone
wants
to
fall
off
my
shirt
today
and
then
you
know,
we've
got
the
pre-sync
user
comparison,
which
is
just
going
to
run
a
compare
of
users.
It
will
require
that
precinct,
zendesk
user
report
and
precinct
salesforce
user
reports
and
that
will
also
create
a
user
creates
the
user
updates
json
file,
artifacts,
which
we
will
use
in
the
scripting
and
then
syncing
is
just
going
to
require
those
comparisons
ran,
and
then
it's
going
to
sync
the
organizations
and
sync
users.
A
A
All
it's
doing
is
requiring
the
zds
fdc
sync
us
federal
script,
and
then
it's
running
zendesk
salesforce,
sync
us
federal
sales
force,
gatherer
accounts
run.
They
all
follow
kind
of
the
same
format.
So
for
like
zendesk
organizations
it'll
be,
you
know,
send
desk
sales
for
sync
us
federal,
zendesk
gather
orgs
run.
Compare
is
going
to
be.
You
know,
desk
salesforce,
sync,
us
federal,
compare
organizations
run
they
all
kind
of
match
the
same
kind
of
format.
A
So
let
me
go
over
the
gem
file
real
quick,
it's
a
very
small
gem
file
because
we
only
really
need
these
three
different
gem
libraries,
json
oj
and
restforce
json.
You
know,
obviously,
a
gym
for
handling
json
request,
helps,
convert
json
strings
to
ruby
objects
and
then
vice
versa.
Ruby
objects,
two
json
strings
oj
is
a
nice
gem
that
I
like
to
use.
It
makes
handling
http,
headers
and
bodies
and
all
that
stuff
easier.
A
The
reason
I'm
using
4.2.2
is
I've
tested
that
that
specific
gym
and
that
specific
version
works.
Future
versions
of
restforce
could
change
api,
endpoints
and
stuff
like
that,
so
they
have
to
be
tested
pretty
thoroughly
before
we
switch
over
to
them
beyond
that's
going
into
the
actual
files
themselves,
the
zd
sfdc
sync
us
federal.rb
file.
It's
basically
just
declaring
the
module,
zendesk
salesforce,
sync
us
federal,
and
then
it's
going
to
require
bundler
setup
and
then
it's
going
to
have
bundler
required
default.
A
The
simple
way
to
explain
this
is
I'm
requiring
the
bundler
setup.
There's
the
setup.
You
know
the
setup
portion
of
the
bundler
gym
and
then
by
doing
bundle
required
default.
I'm
just
telling
it
yeah
that
stuff
in
the
gem
file
go
ahead
and
require
it
because
we
need
it
for
the
scripts.
A
This
only
has
three
requires
that
would
really
be
needed,
but
when
you
start
working
with
scripts
that
are
having
like
20
different
gems,
this
is
a
really
nice
way
to
condense
that
down
and
make
it
quick
and
easy
beyond
that,
you
can
see
we're
requiring
the
client
files.
So
let's
go
over
that
next.
A
All
right,
client
file
there
we
go
so
the
client
file
once
again
we're
declaring
that
module.
Zendesk,
salesforce,
sync
us
federal,
you'll,
probably
get
tired
of
hearing
me
say
that
exact
phrase.
A
lot
then
we're
declaring
a
class
called
clients
we're
requiring
to
compare
salesforce
and
zendesk
scripts.
We'll
go
over
that
in
a
bit.
A
We
make
a
function
called
retry
options.
Basically,
this
is
setting
up
options
we'll
pass
through
faraday
to
tell
it
how
to
handle
failures.
In
specifically
connection
failed
and
timeout
error
do
a
max
of
five
retries.
The
interval
should
be
a
second
long.
We
want
some
randomness
in
the
interval,
so
add
or
subtract
five.
You
know
half
a
second,
the
back
off
factors
too.
A
So
if
we
get
something
that
tells
it
hey,
api
limit
or
you've
been
blocked,
or
whatever
it's
going
to
wait
two
seconds
and
try
again,
we
have
a
salesforce
function
which
is
making
a
salesforce
variable
if
you've
never
seen
the
double
pipe
people.
It's
a
cool
thing
I
like
to
do
in
ruby.
It
basically
says
set
the
variable
to
this.
Unless
it
already
has
a
value.
A
This
is
useful
because
now
I
can
by
doing
this
I
can
call
salesforce
50
times,
and
it's
not
going
to
make
50
restforce
objects
it'll
make
it
once
and
give
me
the
same
object
every
time
so
good
for
you
know
making
sure
you're
not
wasting
memory
in
your
code,
but
beyond
that
we're
just
making
a
new
restforce
object
that
takes
the
host
username,
password,
client,
id
client
secret
security
token
and
we're
specifying
api
version
41..
That's
just
because
that's
been
tested
with
restforce
4.2.2.
A
A
We
also
specify
a
zendesk
object
or
a
zendesk
function
in
that
we
just
make
a
new
faraday
connection.
It's
using
the
us
federal
zendesk
ur
api
url,
we're
passing
it
those
retry
options
telling
it
to
just
use
faraday's
default
adapter
as
the
adapter
for
these
requests.
We
set
the
content
type
to
application
json.
A
That's
because
when
it's
not
really
required
for
get
request,
but
when
you
do
like
a
put
or
a
post
request-
or
you
know
a
delete
request
stuff
like
that,
it's
gonna
expect
json,
it's
gonna
expect
a
json
object
to
parse
it
and
handle
that
request,
and
it's
gonna
return
a
json
object.
So
it's
useful
to
tell
it
yeah,
hey
we're
going
to
be
passing
you
it's
going
to
be
handling
json,
and
then
we
have
the
basic
authentication,
which
is
just
your
username,
that
you're
using
slash
token
and
then
your
api
token.
A
As
a
fun
fact,
basic
auth
is
being
deprecated
in
faraday,
so
in
the
near
future,
we'll
update
the
basic
offline
there
to
use
the
new
non-deprecated
version
of
it,
and
then
we
have
the
request
function,
which
takes
an
http
method
and
a
url
which
will
be
appended
to
this
us
federal,
zendesk
url
up
here
and
then
parameters
we're
sending
to
a
default
hash.
A
But
you
can
pass
parameters
which
override
that
default
hash,
but
essentially
we're
just
doing
a
public
send
on
the
faraday
connect
faraday
object
to
whatever
you
know,
http
method
we're
using
and
then
whatever
url
endpoints.
With
whatever
parameters
we
send
and
we're
taking
the
body
of
that
response
and
using
oj
to
load
it,
so
it's
nice
and
easy
to
parse
before
I
go
further
any
questions
on
the
client
file.
A
Cool
so
I'll
go
to
the
next
part,
we'll
start
with
salesforce.
The
salesforce
rb
file
is
just
requiring
the
gather
script
from
the
salesforce
folder,
not
a
lot.
You
know
happening
there,
but
if
we
go
to
the
gather
file,
there's
that
and
that's
just
requiring
accounts
and
contacts
so
we'll
go
through.
Those
accounts
is
a
good
place
to
start,
but
we're
declaring
that
modules
index
salesforce
same
qs
federal.
We
are
declaring
our
classes
salesforce
we're
clearing
the
subclass
of
that
is
gather
and
then
we're
making
a
subclass
called
accounts.
A
This
less
than
client
is
basically
telling
it
to
inherit
the
functions
from
client
into
this
file,
and
so
we
don't
have
to
redefine
anything
or
have
a
complex
call
out.
That's
like
zendesk
salesforce,
sync,
us
federal,
colon,
colon
client,
dot
salesforce.
A
This
just
allows
us
to
call
it
salesforce,
and
it
knows
what
we're
talking
about
so
the
run
function
which
the
script
uses
it's
going
to
do.
A
gather,
verify
report
and
an
artifacts
function
gather
is
going
to
print
out
that
it's
gathering
data,
it's
going
to
run
the
data
function
and
then
it'll
tell
us
it's
done.
A
A
We're
also
gathering
any
customer
subscriptions
associated
with
each
return
and
each
and
all
the
zuara
subscriptions
we're
going
to
use
those
to
parse
and
try
to
rule
out
false,
expired
and
stuff.
Like
that,
we're
gathering
all
this
from
the
accounts
table,
which
is
to
say
it's
an
account,
object
in
salesforce,
and
then
we
have
our
criteria
here.
This
is
the
criteria
for
us
federal
accounts.
A
They
have
to
be
a
customer
former
customer
prospect.
Admittedly
that's
a
little
redundant
because
that's
pretty
much
every
type
of
account
that
can
exist
in
salesforce
beyond
that.
It's
like
a
lead,
but
there's
also
partners,
so
that
kind
of
helps
the
account
territory
has
to
be
in
the
format.
U.S
pub
fed
blob
if
you're
not
familiar
print
site
percentage
sign
in
sql
and
soql.
In
this
case,
it's
a
blob,
it's
a
wild
card.
A
We're
going
to
pass
into
account,
object
to
give
us
this
nice
pretty
hash
in
a
format
that
will
be
comparable
to
zendesk
later,
but
first
we're
running,
check
account,
which
is
doing
this
right
here.
This
giant
thing
right
here
and
to
summarize
what
this
is
doing,
we're
essentially
going
over
the
subscriptions
and
the
zorus
subscriptions
looking
at
the
various
plans
that
they
have
in
them
the
various
names
and
we're
trying
to
take
that
and
gather
every
type
of
plan
they
might
have.
A
So
if
the
plan
contains
the
word
ultimate,
it'll
have
it'll
get
this
ultimate
one,
or
one
ultimate
string
added
to
a
plans
array
which
we're
having
we're
starting
up
here
with
expired,
we're
running
a
unique
on
it,
just
to
kind
of
eliminate
duplicates,
because
we
might
end
up
seeing
oh
well,
their
support
level
was
ultimate
and
they
had
a
customer
subscription
for
ultimate
and,
as
you
wore
a
subscription
for
ultimate,
which
are
all
the
same
exact
thing.
So
it's
going
to
get
three
ultimates.
A
A
This
is
why
each
of
these
have
a
number
so
that
they
kind
of
have
a
value,
a
hierarchy
of
this
obviously
ultimate's,
the
top
tier
and
then
premium
then
starter
custom
at
the
bottom
there,
if
you're
wondering
why
it's
skipping
numbers,
this
is
copied
over
from
the
main
instance,
and
that
has
way
more
plans.
They
can
have
this
one
in
u.s
federal.
A
We
only
have
these
basic
plans
here,
so
we
don't
have
to
worry
about
it
as
much,
but
what
we're
essentially
doing
this
p1
dot
negative
one
is
basically
just
stripping
off
that
number
at
the
beginning,
so
we're
basically
just
getting
all
the
subscriptions
without
these
numbers
to
help
us
sort
it
and
then
we're
using
unique.
Once
again,
this
is
actually
pretty
redundant.
You
don't
have
to
do
that.
It's
there.
I
don't
know
why.
I
didn't
remove
it,
but
it's
there.
It
doesn't
hurt
anything
we're
setting
the
support
level
to
the
highest
plan.
A
A
A
All
that's
going
to
do
is
make
a
duplicates
object
and
set
it
to
determine
duplicates
which
we'll
go
down
here
and
look
at
and
all
determine,
duplicates
is
doing,
is
grouping
all
of
these
salesforce
accounts
by
their
name,
lowercase
all
lowercase,
because
zendesk
is
not
case
sensitive
when
it
comes
to
naming
and
any
of
them
where
it
sees
two
of
them
have
the
same
name
or
two
or
more
have
the
same
name
essentially
more
than
one
of
them.
It's
gonna
actually
mark
these
as
duplicates
the
reason
for
that
is.
A
We
can't
sync
both
to
zendesk
when
they
have
the
same
name.
We
can't
easily
determine
via
scripting,
which
one
is
the
true
account,
so
we're
just
going
to
strip
those
out
and
warn
about
them.
In
our
report
report,
you
know
it'll,
say
hey.
I
found
this
many
accounts.
These
are
how
many
duplicates
I
found
and
it's
going
to
print
out
the
salesforce
id
and
name
of
each
duplicate.
A
A
Cool,
so
the
the
other
one
would
be,
for
the
gather
would
be
contacts
it's
going
to
be
very,
very
similar
to
accounts
it's
going
to
basically
run
the
same
thing.
A
The
big
differences
here
is
obviously
the
soql
is
considerably
shorter,
because
we
don't
need
near
as
much
information,
and
we
actually
also
have
to
check
if
the
name
or
email
is
missing
or
blank,
because
we
can't
sync
those
can't
create
those,
so
it
will
strip
those
out
too
same
for
duplicates,
and
then
our
reporting
will
also
tell
us
when
the
name
and
email
is
missing,
so
that
we
have
that
information.
A
A
Once
again
we
declare
our
module,
then
the
classes
and
subclass
gather
subclass
organizations
inherit
from
client
and
all
run
is
going
to
do
is
generate
the
artifact
and
report
generating
the
artifact
is
going
to
do
data.json,
so
we're
going
to
run
data
which
gathers
the
orgs
here's,
the
real
meat
and
potatoes
of
how
we
get
that.
Essentially,
we've
got
an
empty
array,
we're
setting
the
page
number
one
and
we
are
going
through
every
page.
A
A
The
only
big
things
here,
it's
doing
differently.
Is
we
clean
out
the
tags
to
remove
subscription
tags
because
we
don't
want
to
compare
that
the
support
level
all
this
does
is,
if
it
sees
it,
says,
starter
or
sorry.
If
it
sees
it,
says
the
word
basic.
It's
going
to
replace
it
with
starter,
because
basic
is
a
deprecated
name
and
starter
is
the
actual
name.
A
So
we
just
want
to
make
sure
to
replace
those
so
they're,
all
consistent
and
yeah
determined
subscriptions
just
going
to
look
through
the
actual
tags,
make
sure
it
has
all
the
correct
subscriptions
present
all
that's
going
to
get
generated
to
zendesk,
zendesk
orgs.json
and
it
will
report
hey.
I
found
this
many
organizations
any
questions
there
before
I
go
to
the
other
one
cool,
so
the
users
it's
going
to
do
pretty
much
the
same
thing
except
this
time,
we're
going
through
the
users
we're
telling
it
to
include
organizations.
A
A
So
beyond
that,
we've
got
our
compare
script.
This
is
just
going
to
require
the
organizations
and
user
scripts
from
compare
so
we'll
go
in
there
for
organizations.
You
know
we
declare
our
module
declare
a
class
declare.
Our
subclass
run
is
going
to
do
a
compare
generate
and
report.
We
set
some
variables
just
for
counting
measure
just
for
having
an
array
for
easier
artifacts.
A
The
compare
script
we're
going
through
all
the
salesforce
accounts.
I've
got
this
nice
little
printout
that
it's
going
to
tell
me
what
number
accounts
it's
on
and
all
that
that's
just
so
when
I'm
debugging.
I
can
look
at
this
and
see
it's
still
running,
because
I
can
see
that
number
incrementing.
A
A
If
we
do
not,
we
need
to
create
it
so
it'll
push
it
to
the
creates
it'll
push
a
create
object
which
will
go
over
to
otherwise
it's
going
to
run,
determine
update
and
then,
when
it's
done,
it'll
print
out
done
for
determine,
update,
we're
going
to
make
a
comparable
object,
which
is
to
say
we're
deleting
id
and
tags.
We
obviously
there's
not
a
zendesk
id
in
salesforce,
so
we
got
to
get
rid
of
that.
There's
not
tags
in
salesforce.
A
A
A
We've
got
the
sync
script
which
is
going
to
require
you
know
sync
orgs
and
sync
users,
so
we'll
go
into
organizations
first,
you
know:
we've
got
our
module
declaration
class
to
desk
subclass
subclass
organizations
and
then
inherit
from
clients,
and
here
we've
got
create
for
the
run
function.
We've
got
created,
update
errors,
create
org,
sync
words:
report
created
setting
to
zero,
updated
to
zero
errors
is
an
empty
array.
This
is
just
for
reporting
measures
for
creates,
we're
gonna
essentially
go
through
them.
A
A
If
there's
any
error,
it'll
print
that
out
over
into
the
errors
erase
we
can
report
later,
this
is
an
organ
the
create
object.
This
is
the
exact
format
that
zanes
wants
it
in
to
create
an
organization.
Without
this
it's
gonna
either
say
hey.
I
created
it,
but
I
didn't
really
because
you
didn't
give
me
a
right
format
or
it's
gonna
return
with.
I
can't
understand
the
paylift
so
important
to
get
that
right
format
for
updating
them,
we're
going
to
slice
them
into
100
chunks
of
100
orgs.
At
a
time
this
is
so.
A
We
don't
want
to
do
that,
so
instead
we're
going
to
do
it
this
way
and
we're
just
going
to
bulk
update
them
100
at
a
time,
and
this
will
use
this
update,
object
to
print
them
in
the
exact
format
that
zendesk
wants
from
there
we'll
report,
how
many
we
created,
how
many
we
sync,
if
there's
any
errors,
it'll
print
out
the
string
to
tell
us
what
went
wrong
with
them,
but
yeah.
That's
that's
pretty
much
it
for
that.
There's
also
the
sync
users.
A
This
one's
doing
pretty
much
the
same
thing.
We're
gonna,
do
the
creates
the
same
kind
of
method
for
the
update
mini.
You
know
we'll
slice
them
into
100..
This
pretty
much
says
the
exact
same
thing
the
organizations
did,
but
for
users.
A
And
that's
really
all
there
is
to
what
the
zendesk
u.s
federal
sync
salesforce
sync
does.
This
runs
via
schedule,
every
30
minutes.
This
is
how
we
kind
of
pre-populate,
the
orgs,
make
sure
they're
up-to-date
pre-create
users
as
an
important
as
a
fun.
Little
side
note
there
is
a
limit
where
we
can't
get
all
the
users,
because
the
amount
of
time
it
will
take
surpasses
what
we
can
actually
feasibly
do,
or
the
number
of
api
calls
surpasses
what
we
should
be
doing.