►
Description
Jason Colyer, Support Operations Manager, takes us through how to manage Zendesk agent signatures via the sync repo
A
A
So
this
is
the
sync
repo
for
the
global
instance.
The
one
for
us
federal
is
going
to
look
very,
very
similar,
maybe
some
slight
tweaks
to
the
formatting
used
because
they're
two
different
instances,
but
generally
speaking
what
we
have
here,
our
repo
and
this,
where
we
tend
to
manage
it.
So
to
start,
let
me
kind
of
go
over
how
this
works
and
then
we'll
go
into
actually
making
changes.
A
A
All
it
does
is
require
the
agent
signatures
file
and
then
calls
the
run
function
so
where
a
lot
of
this
is
actually
going
to
come
from.
Is
this
agent
signatures
file,
and
here
we
specify
a
class
of
asian
signatures?
This
requires
the
yaml
and
the
zendesk
api,
gems
or
libraries,
depending
on
how
you
want
to
define
the
yaml
stuff.
But
first
we
start
by
defining
a
client,
in
this
case
the
zendesk
api
client,
we're
passing
at
the
url
username
token
retry
and
then
we're
turning
the
logger
to
a
false.
A
Just
to
prevent
the
overly
proposed
wording
that
it
will
use.
We
also
define
a
gitlab
client.
This
will
use
a
new
faraday
connection
using
whatever
default
adapter
is
available.
It's
going
to
make
sure
the
request
is
url
coded
and
it's
going
to
pass
the
private
token
header
in
there
using
our
gitlab
token.
A
Now
we
all
specify
the
get
lab
request
function.
What
this
does
is
take
the
http
method,
the
endpoint
and
any
parameters
we
want
to
pass
into
it,
and
it's
going
to
call
the
public
center
function
of
the
client,
which
is
faraday
using
that
information,
and
then
it's
going
to
come
back
with
whatever
response
it
has
and
safe
load
it
using
enamel
we're
passing
the
date
in
there
that
way.
It
goes
to
parse
dates
as
dates,
and
then
we
have
the
get
support
team
function.
A
This
is
basically
calling
a
url
to
the
support
team
ymo
file
and
we're
just
calling
the
git
lab
request,
calling
a
get
request
with
url.
Basically,
we
just
want
the
raw
yaml
file
that
is
stored
there
and,
of
course,
animal's
going
to
parse
that
and
have
it
for
us
so
that
we
have
our
support
gemml
file
loaded
in
there
as
a
ruby
object,
so
we're
good
to
go.
A
There's
the
agents
function,
which
is
just
setting
the
agent's
global
variable
to
get
support
team
yaml,
which
again
is
just
going
to
get
the
support,
tdml
and
parsing
it
to
ruby.
For
us,
the
signature,
we
read
the
data
signature.txt
file,
we'll
go
into
that
in
a
bit
and
then
there's
the
run
function,
which
is
pretty
much
going
to
go
through
every
agent
that
we
have
from
that
support
team
yaml
file.
A
It's
going
to
tell
us
it's
updating
that
agent
and
then
it's
going
to
run
the
update
signature
function
using
the
agent
and
then
it's
going
to
tell
us
it's
done.
That's
all
the
run
function
really
does
all
the
update
signature
function
in
of
itself
does
is
called
the
zendesk
api
to
update
the
user's
signature
update
the
user
specifically.
A
But
all
we're
really
tweaking
is
a
few
things
of
the
user
and
what
that'll
do
is
get
an
update
object
using
the
agent
information
and
the
update
object
is
going
to
have
the
agent's
zendesk
id
their
name,
the
signature
that
we'll
define
down
below
and
then
we're
also
going
to
pass
it
the
get
lab
username
and
get
live
user
id.
These
are
used
on
some
other
triggers
and
automation.
So
it's
good
to
have
that
pre-populated
for
agents.
A
Now
the
actual
agent's
signature
itself,
it's
going
to
look
to
see
if
the
agent
has
any
salutations.
This
is
something
you
can
define
in
the
supporting
animal
file.
Things
like
have
a
nice
day.
Warm
is
for
guards
et
cetera,
et
cetera,
there's
a
function
for
that.
We'll
go
over
that
a
bit
after
the
salutation.
It's
gonna
have
the
agent's
name
their
title
and
then
get
lab
support,
link
to
get
lab
support
and
then
we're
gonna
have
the
feedback
form,
which
is
something
newer
to
the
agent
signatures.
A
Now
the
agent's
title
is
is
literally
just
what
their
title
is
defined
as
the
support
team,
the
feedback
form
itself.
We've
basically
got
this
block
of
text
here
that
links
to
this
feedback
form
we're
currently
using.
This
will
make
sure
it
appends
it
at
the
end
of
the
agent
signature
so
that
it's
present
on
every
reply
from
a
gitlab
agent,
the
salutation
itself.
It's
gonna
return
blank.
If
there
is
no
salutations,
but
if
there
is
one
it's
going
to
pull
a
random
one
for
the
day,
it
doesn't
always
use
the
same
one.
A
It
runs
sample
function
for
those
familiar
encoding.
Yes,
random.
Being
truly
random
in
code
is
not
really
easy
or
simple,
but
I
just
use
the
sample
function.
It
feels
good
enough
for
this
case,
so
all
that
will
run
and
update
the
signatures.
The
other
component
to
know
here
is
that
agent
signatures
data
file.
A
A
While
we
call
what
we
have
a
function
to
read
that
we
don't
actually
use
it
in
the
signature
itself.
This
is
by
attention.
It
was
something
we
tried.
We
didn't
like:
we've
kept
it
there
in
case
we
ever
want
to
go
back
or
use
other
kind
of
messaging.
For
that
now,
the
way
all
of
this
works
is
it
runs
on
a
daily
cicd
schedule
that
we've
got
set
in
here.
It's
going
to
run
every
24
hours
to
sync
these,
and
if
you
look
at
this,
it
runs
every
day
at
midnight.
A
Utc
time
in
this,
we
pass
the
variables
that
we
need
to
pass.
That's
all
there
really
is
to
agent
signatures
itself
and
how
it
works.
So
if
you
were
to
need
to
make
a
change
as
of
right
now,
you're
going
to
be
doing
it
via
the
agent
signatures,
dot,
rb
file
in
the
lib
folder
and
basically,
what
you're
normally
going
to
change
is
the
formatting
used.
Here
we
might
sync
some
other
fields
or
something
along
those
lines.
A
You
might
have
to
update
the
update
object
or
we
might
decide
not
to
use
the
feedback
form
or
et
cetera,
et
cetera,
it's
going
to
depend
on
what
the
request
is,
but
basically
you're,
going
to
make
the
edit
here
click
the
web,
ide
or,
however,
you
prefer
to
edit
make
the
edit
create
an
mr
get.
It
approved,
get
it
reviewed
by
the
requester,
get
it
merged.
That's
basically
the
process
for
making
a
change
to
the
agent
signature,
because
it
runs
once
a
day.