Community Discussion: Using Sandbox for Workflow Changes

29 Commentaires

  • Commentaire officiel
    Kristen Mirenda
    Actions pour les commentaires Permalien

    Thank you so much to everyone who's chimed in already! This info is really valuable -- please keep it coming.

    I'm planning to do some surveys and interviews in the coming weeks. If you're interesting in participating, here's a Google form to sign up:

    https://goo.gl/forms/R4xZXHCNm2Kb32zq2

    Looking forward to talking to (many of) you soon!

  • info
    Actions pour les commentaires Permalien

    As an administrator/manager, what’s your current process for setting up and modifying workflow rules (triggers, automations, macros, views)?

    I'm forced to do it on the fly in the live system and accept that some of my customers may get weird emails they don't understand. We've been using Zendesk since 2012 and we're managing high volume with a small team so I have A LOT of automations and triggers that we've built up over many years to deal with that volume. They're all interconnected and have gotten reasonably complex. Invariably there's going to be something that misfires when I make a change and it's really unprofessional in my view for our customers to get roped in when I'm making changes.

    Unfortunately, it's what we have available to us since we can't duplicate the current live DB settings to the sandbox so we make do.


    Do you use the Zendesk Sandbox in this process and if so, what are the steps?

    Nope. The current sandboxes are totally useless to me without our current settings and I would have to replicate it by hand to get that so that's not happening. By the time I figured out that my only option was to do this manually we were a year in to automations and there was no way I was going to try to replicate it exactly by hand.


    What's working well? What's not working well?

    As above, it's not working at all because I can't use :)


    What data do you need to be in the Sandbox for you to do this, and how do you get it there?

    Reastically I would like the sandbox to work as a sort of staging area for us to test changes/improvements. That way the process becomes: make changes & test in the sandbox and then apply them to the live system so it now matches the current sandbox settings. This means that each time you go to make changes you can troubleshoot oversights in your triggers etc. without causing problems with customers and only push the chnages once you're sure they'll work.


    What data is not there that you need?

    All of my settings from the live database.

    This includes but is not limited to: triggers, automations, custom user and ticket fields, external channels (for testing triggers based on FB messages, twitter etc), & support schedule (for triggers based on business hours).


    Do you use the Sandbox for things other than making workflow changes?

    Again, not using it now because manually copying my settings is prohibitive but I can't see having any other use for it off the top of my head. Doesn't mean there isn't one, just that improving workflow would be our primary usage were copying settings fro the live DB to become available.

     

    Hope that helps and thanks for looking into this!

    10
  • Zac
    Actions pour les commentaires Permalien

    As an administrator/manager, what’s your current process for setting up and modifying workflow rules (triggers, automations, macros, views)?

    We set up our processes manually in production. If we are testing behavior of triggers with a new ticket field, or some new use case such as how a trigger interacts with a ticket field that's not on the current ticket form (at one point, we didn't know!), we test it in Sandbox. However, for the most part we don't get valuable testing of our actual workflows in Sandbox - just a better understanding of how the technology will behave. We have to circle back in production and integrate it into our existing workflows (comprised of a large existing set of triggers that set ticket fields and tags) without breaking anything.

    Do you use the Zendesk Sandbox in this process and if so, what are the steps?

    We use the Zendesk Sandbox minimally - primarily for what you might call "unit testing". We can't test our actual processes, but if we have an idea of leveraging a Zendesk feature for that process, we'll test its behavior in Sandbox before using the same concept in production.

    What's working well? What's not working well?

    Working well:

    • The fact that Sandbox is a "vanilla" instance works well for us. We can test new functionality in isolation.
    • We can test how new apps or feature might work. This is helpful both for trying out Marketplace apps, and for our development of custom apps and integrations.

    Not working well:

    • The fact that Sandbox is a "vanilla" instance. Sometimes, we need to layer something into our existing atmosphere of automations, triggers, tags, macros, custom ticket fields, ticket forms, custom user fields, organization fields, conditional fields, and other app integrations, to get a feel for how a new automation or process will work in "real life".
    • After configuring a new process in Sandbox, it has to be manually configured again in Production.


    What data do you need to be in the Sandbox for you to do this, and how do you get it there?

    Need the following from Production:

    • Automations
    • Triggers
    • SLAs
    • Tags
    • Macros
    • Groups
    • Views
    • Organizations
    • Custom Roles
    • Custom Ticket Fields
    • Ticket Forms
    • Custom User Fields
    • Custom Organization Fields
    • Conditional Fields
    • All Settings (such as tickets settings, agents, customers, etc.)

    What data is not there that you need?

    None of the above bullet points are in Sandbox unless I manually configure them. Some of the settings, we have manually configured and can persist (e.g. Groups), others we have left alone so our Sandbox is a better "unit testing" playground (such as Triggers).

    Do you use the Sandbox for things other than making workflow changes?

    • We use Guide in sandbox to test development concepts.
    • We test new apps in Sandbox
    4
  • Jane Sun
    Actions pour les commentaires Permalien

    Sooo excited that you guys are considering this function.

     

    As an administrator/manager, what’s your current process for setting up and modifying workflow rules (triggers, automations, macros, views)?

    I just set it up in production and send in test tickets into the production environment. ( Luckily, our volume still allows us to do so)

    Do you use the Zendesk Sandbox in this process and if so, what are the steps?

    I do not. All my workflow changes are pretty simple, it's just too time consuming to set up workflow, test tickets in sandbox, and then have to recreate this in production.

    What's working well? What's not working well?

    I do not use sandbox because it does not copy everything from production.

    What data do you need to be in the Sandbox for you to do this, and how do you get it there?

    I would love that Sandbox can copy current settings, and copy the current tickets that we have so I can test. It doesn't have to be a real time sync, even if it's the data from a week before will work for me.

    What data is not there that you need?

    All the current workflow, settings, macros, as well as test tickets.

    Do you use the Sandbox for things other than making workflow changes?

    Test in general.

     

    Hope that helps, and thanks for looking into this.

     

    4
  • Dan Ross
    Actions pour les commentaires Permalien

    Hi Kristen! 

    Thanks very much to you and the Community Team for hosting this! 

    This has been a massive pain point for us since we started using Zendesk and is the top issue for us in terms of areas we are hoping for improvement for Zendesk. 

    We deal with ~1,000 tickets a day. Not having a copy of our prod environment prevents us from innovating quickly and we've backed away from a few projects because of the risk involved in doing it in production or the cost of doing it in the sandbox.

    We effectively *don't* use the Sandbox, as the overhead to maintain it is too high. Every single change needs to be manually replicated in Sandbox.  

    We have over a hundred custom fields, nearly 200 triggers, easily a dozen forms and we're only growing.  Changes occur daily.

    Even if we did take the effort to duplicate every change into the sandbox by hand, there's no functional way to *know* that you're up to date and working off a copy of your production environment. 

     

    As an administrator/manager, what’s your current process for setting up and modifying workflow rules (triggers, automations, macros, views)?

    Setup Triggers:

    To work around the problems described above, I will generally create a trigger, but require that the current user is equal to me, so that no other agents trigger them. 

    Modifying triggers:

    This is much harder, as these are workflows that are already in place and relied upon by agents. Generally it involves a 'educated guess' approach with rapid testing. Sometimes I'll duplicate the trigger, and add the Current User requirement equal to me and then update the original to fire for anyone NOT equal to me. This will let me test a trigger in parallel to existing ones in production. 

    Developing in production is NOT anywhere close to best practices for systems management - I can't stress this part loudly enough.  There's little to save you if you mess things up, although the Trigger Revisions feature does help now. (thanks for that!)

    Sometimes, you need to evaluate changes over a period of time (days, weeks) to ensure there's no unintended consequences. A copy of production would be great for that.

    Do you use the Zendesk Sandbox in this process and if so, what are the steps?

    Nope. Without an up to date copy of our existing schema, it's not useful.


    What's working well? What's not working well?

    I tried really hard to be positive, but realistically, nothing about the current Sandbox feature is working well.  We did try using it for Guide development at one point but when the non-Copenhagen themes were removed, we could no longer test against our existing setup.


    What data is not there that you need?

    Zac pretty much nailed this.

    • Automations
    • Triggers
    • SLAs
    • Tags
    • Macros
    • Groups
    • Views
    • Organizations
    • Custom Roles (we tried to write a sync tool on our own and this is what killed it. There's no write API for custom roles!)
    • Custom Ticket Fields
    • Custom User Fields
    • Custom Organization Fields
    • Ticket Forms
    • Conditional Field setting
    • All Settings (such as tickets settings, agents, customers, etc.)

    While I'm dreaming, a subset of end-users and organizations would be nice.

    Our existing applications. Some are paid, which mean we need to buy another license to use them in our Sandbox today. 

    Do you use the Sandbox for things other than making workflow changes? 

    Testing new features in isolation. Testing API calls.  

     

    Thanks for reading! If you have any questions, I'm happy to make myself available for call or screenshare to show how we work and the kinds of issues not having a synced sandbox causes.

    3
  • Peter Hochstrasser
    Actions pour les commentaires Permalien

    Hope this passes the information gathering stage rather quickly!

    What do we do:

    • As an administrator/manager, what’s your current process for setting up and modifying workflow rules (triggers, automations, macros, views)?
    • as outlined above, there's no real safe way to do this if you want all to check all brands and features. So, we do it in the live system, and from time to time, we're punished for this. We had this one case where an admin did her first trigger, and she didn't have all the conditions right. The resulting mail flood has been ... interesting.

    • Do you use the Zendesk Sandbox in this process and if so, what are the steps?
      We tried, but we failed. Too little functionality is taken over, too much is to be re-done by hand, so, no, we don't use it anymore at this time.

    • What's working well? What's not working well?
      Not working well: Too few configurations are taken over, you basically start from scratch and re-implement production before you can start to test. This is way too much effort, and due to the limitations regarding interfaces, extensions etc. not worth the effort.

    • What data do you need to be in the Sandbox for you to do this, and how do you get it there?
      As much configurations as possible. Especially triggers, automations, macros, ....

    • What data is not there that you need?
      See above.
    • Do you use the Sandbox for things other than making workflow changes?
      In its current state, we cannot use it effectively. We'd love to be able to test extensions and their configuration (do we send the right information to the external system, do we get correct information back), but that is a stretch.
    1
  • Serena De Biasi
    Actions pour les commentaires Permalien

    Here my contribution to the thread:

    • As an administrator/manager, what’s your current process for setting up and modifying workflow rules (triggers, automations, macros, views)?
      For slight changes we directly operate in production (and this is NOT how we are used to manage SW development).
      In order to perform these open-heart changes, we created a subsets of customers, agents and light agents (all fake) that we use as testing micro-environment.
      We also created architecture & relational maps of all the elements, triggers, automations mapped into production.
      When we are quite confident, we extend the changes to other units, step by step, verifying the environment at each step.


    • Do you use the Zendesk Sandbox in this process and if so, what are the steps?
      First of all, we analyze the scenario using our architecture & relational maps.
      We then design what to change and how to do it, "on paper", in order to list to-dos and checkpoints BEFOREHAND.

      Then, we move to the dev phase: we had to purchase an additional plugin in order to obtain a better testing environment that at least automated the mapping of triggers and automations.
      We apply the core changes of the workflow, the ones that have bigger impacts.
      When we are confident, we re-map manually in production or we use the plugin, in case of triggers or automation.


    • What's working well? What's not working well?
      I'll try to be clear:

      A. The overall workflow of creating a testing environment, dev & deploy it back to production should be effortless. It is not.

      B. A testing environment should be a CLONE of the production one. I do understand that automated emails to customers can be a hassle but you can easily manage this point mapping and re-mapping email accounts: in testing environment you can as example emulate the email flow to end-users using a dedicated dashboard where developers can understand what each end-user receives, then emulate a reply, etc...

      C. We want a "deploy" button.
      When we are sure of the new settings, we simply want to press a button that transfers ALL the settings to production.

      D. We want restore points, both in production and in sandbox!

    • What data do you need to be in the Sandbox for you to do this, and how do you get it there?
      See prev point

    • What data is not there that you need?
      See prev point.

    • Do you use the Sandbox for things other than making workflow changes?
      Yes: REPORTS.
      It would be nice to understand beforehand how changes impact active reports and have the chance to also "move to production" the reports.

     

    3
  • Leif-Arne Kristiansen
    Actions pour les commentaires Permalien
    • As an administrator/manager, what’s your current process for setting up and modifying workflow rules (triggers, automations, macros, views)?

      We implement changes on the fly in the productions system. As a rule we are careful about making changes that are not strictly necessary, since the risk of errors is there and it's not ideal to do testing on a live system. One thing we do in order to test triggers and automations in a somewhat safe way is to add a crtieria to a new trigger, like for example only to trigger on tickets from selected users, so that we can test and make sure it works with chose users before we remove that limitation and let it run for everyone.

    • Do you use the Zendesk Sandbox in this process and if so, what are the steps?

      We do not use the Sandbox, as it is way to much effort to manually replicate the setup from production to Sandbox, then make changes and test, and then replicate those changes manually to production. The pain of live testing is smaller.

    • What's working well? What's not working well?

      In my opinion, Sandbox doesn't work. Having a blank slate can be useful in some instances, like if you want to completely rebuild your entire workflow from scratch, but for tweaking an existing setup it's totally unusable. 

    • What data do you need to be in the Sandbox for you to do this, and how do you get it there?

      My idea of an ideal sandbox is this: 
      The sandbox should offer an option to import every trigger, macro, automation etc from the production system. Tickets should also be transferable, but maybe by user choice - for example, the user can choose specific tickets, or all tickets from a certain date span.

      It should be possible to enable a continious sync from production to sandbox, so that if we make a change in production it is automatically replicated back to the sandbox - but this option should be possible to disable. It should also be possible to select triggers, automations, macros etc that have been modified in sandbox, and push them to production automatically.  These pushes should be logged in some way and offer a rollback option.

    • What data is not there that you need?

      Basically everything, as described in the previous point.

    • Do you use the Sandbox for things other than making workflow changes?

      No.
    2
  • Jessie Schutz
    Actions pour les commentaires Permalien

    Thank you all for your thorough answers! This is great!

    2
  • Pulse
    Actions pour les commentaires Permalien

    Hopefully not too late to the party!

    • As an administrator/manager, what’s your current process for setting up and modifying workflow rules (triggers, automations, macros, views)?

    Changes are made to the live system.

    • Do you use the Zendesk Sandbox in this process and if so, what are the steps?

    No, because many of our triggers and automations rely on other triggers and automations, so having an empty sandbox is totally useless in that regard.

    • What's working well? 

    The fact it's isolated from our live help centre ensures we can test things without them affecting our customers.

    • What's not working well?

    The sandbox is pretty much useless unless I want to start from scratch.

    • What data do you need to be in the Sandbox for you to do this, and how do you get it there?

    Everything! The sandbox needs to have everything everyone else has already mentioned. 

    • What data is not there that you need?

    Everything.

    • Do you use the Sandbox for things other than making workflow changes?

    One big thing I'm currently working on is a site redesign. Our Help Center currently uses Humble Squid, which is no longer supported, so I'm toiling away and a new design using Copenhagen in the sandbox... but I know to move it over to our active HC, I'll need to copy the text from over a dozen different templates, ensure my links to graphics won't get broken, etc... 

    Here's what I need in a sandbox...

    An environment where I can mess around to my heart's content, with an internal loopback / simulated send for things like notifications and triggers, so real live human users aren't receiving a ton of email notifications when one of my sandbox triggers goes bonkers.

    I need to be able to drag my current configuration, including all users, groups, settings, triggers, automations, macros, dynamic text -- everything, into a sandbox. I then need to be able to push whatever elements I want back into the live site. If I only wanted to move the design changes, perfect. If I only changed triggers, migrate those.

    It's a big ask, but it would be vastly more functional than what is currently provided. Thanks!

    2
  • Peter Hochstrasser
    Actions pour les commentaires Permalien

    After reading Pulse's entry, I have one more suggestion for your product development/management which is related, but does not fall into the sandbox category:

    - Add a placeholder for triggers to add their complete name.

    Currently, we have the policy to add a final line to each trigger that sends mails which adds its complete name to the mail so that we know where a "strange mail problem" originates when we're made aware of it by our customers and colleagues. It looks like

    -- sent by Notify 1st Level Support of new tickets --

    if sent by trigger "Notify 1st Level Support of new tickets". It is placed after the body of the ticket, so at the very bottom of the mail being sent.

    There is a good chance that somebody who creates new trigger not from scratch but copies it from another one forgets to update this line. Having a placeholder to generate this kind of information would help and would make the feature available for those who'd like to use it.

     

    0
  • Jordan Kerr
    Actions pour les commentaires Permalien

    @Peter Hochstrasser - your request is product feedback and not at all related to this particular thread. Have you considered creating a new post?

     

    To follow up with my feedback to this thread:

    • As an administrator/manager, what’s your current process for setting up and modifying workflow rules (triggers, automations, macros, views)?

    Like other people have already mentioned, I test this in my live environment because you leave me with no other choice. The sandbox is not a mirror of our productive environment.

    • Do you use the Zendesk Sandbox in this process and if so, what are the steps?

    See above.

    • What's working well? What's not working well?

    The sandbox in it's current state only provides us with an environment to test new apps and customizations of the guide. It's pretty limited otherwise.

    • What data do you need to be in the Sandbox for you to do this, and how do you get it there?

    I need the sandbox to be a 1:1 match of our productive Zendesk environment with the exception of users. This is currently not possible without building it painstakingly by hand.

    • What data is not there that you need?

    All triggers, all automations, all views, all apps, all groups. Essentially every single customized part of our productive Zendesk environment.

    • Do you use the Sandbox for things other than making workflow changes?

    As above, we also use it for testing customizations to our guide. Of course the guide provides at least an opportunity of manually copy/pasting all customized content from the Theme Editor.

     

    Ideally I'd like to be able to test anything and everything in the sandbox with the knowledge that results would be an accurate representation of results from the live production environment. This is only possible with a 1:1 copy.

    Additionally, if I make a new macro/trigger/automation - I'd like to have the option to push that change into the live production environment.

    0
  • Peter Hochstrasser
    Actions pour les commentaires Permalien

    Done.

    0
  • Pulse
    Actions pour les commentaires Permalien

    How timely! This Zendesk announcement rolled in this morning -- it's one of the main reasons I needed full duplication in our sandbox. It brings us one step closer and solves some of my questions / problems, but per the comments above, a proper 1:1 mirroring of the live environment is still needed for testing triggers, etc.

    0
  • Mindaugas Verkys
    Actions pour les commentaires Permalien

    The main points should be ability also to create more than 1 sandbox. 
    Possibility to create same ID's in production would improve testing API.
    Try to test SalesForce SB example - it's almost perfect. :)

    1
  • Renée Gray
    Actions pour les commentaires Permalien
    • As an administrator/manager, what’s your current process for setting up and modifying workflow rules (triggers, automations, macros, views)?

    I am doing this in a live environment which makes me very nervous.  We should be able to make changes in the Sandbox which should be an exact replica of production even if there are customizations and then push the approved changes to production.

    • Do you use the Zendesk Sandbox in this process and if so, what are the steps?

    We only use Sandbox at this point to create and test forms prior to manually moving the form to production.  Even then, you can't test the forms on Help Center.

    • What's working well? What's not working well?

    This is not working well at all. 

    • What data do you need to be in the Sandbox for you to do this, and how do you get it there?

    To manage sandbox today it would be a full time job.  When Sandbox is refreshed it wipes out all of our API connections to our test environments to systems like SAP and SuccessFactors.

    • What data is not there that you need?

    We need everything.

     

    • Do you use the Sandbox for things other than making workflow changes?

    No because Sandbox is a shell of our production environment.

    The bottom line is the current Sanbox environment is not worth my time.

    0
  • Heather R
    Actions pour les commentaires Permalien

    Thanks for listening!

    • As an administrator/manager, what’s your current process for setting up and modifying workflow rules (triggers, automations, macros, views)?

    I have a painfully manual guide for myself as an admin - I have screenshots of every trigger, automation and setting, excels with our custom fields and the included dropdowns, a chart with our customized emails and which groups they route to, etc. It's a huge document.

    When we want to do something new, I have to determine the risk - is it risky enough that I have to do in sandbox first or not? So, larger things like testing Multi-branding and new Apps we DO test in sandbox.  More straight forward things like updates to triggers and automations, I tend to take case by case but usually straight to production because most of the existing triggers and automations don't exist on the sandbox!

    • Do you use the Zendesk Sandbox in this process and if so, what are the steps?

    Yes in some circumstances as mentioned.  We will enable a new app and play around with it and engage super users (Agents).  Or we use sandbox see how a particular feature will work for us such as Chat. We would never enable something as large as these on our Production instance!

    • What's working well? What's not working well?

    We don't have all our Production Automations/Triggers/Apps on the Sandbox. We don't have all the groups and Agents set up, nor the Organizations.  Therefore, it's hard to test as in real-world testing on the Sandbox the way it currently works which is manual!  On the other hand, it works well for large tryouts like Multi-branding, Conditional fields, Chat, etc because it is completely separated from Production.

    • What data do you need to be in the Sandbox for you to do this, and how do you get it there?

      • Automations
      • Triggers
      • Apps
      • Groups
      • Organizations
      • Agents

     

    • What data is not there that you need?
      • Guide Categories/Sections/Articles
      • Some ticket history would be great!!!! -- to use real world testing on timed automations or other time-related feature including reports
      • User data - with NONSENSICAL emails!! We need lots of different end users to test their permissions/access and how their tickets will flow but obviously a copy from production would use their actual emails -- we would not want that!

     

    • Do you use the Sandbox for things other than making workflow changes?

    Yes, as stated above we use it to test new functionality such as when we customized a CSAT with Survey Monkey or tried out Chat, and when we try out new Apps, Customized Fields, etc.

    0
  • Hillary Latham
    Actions pour les commentaires Permalien

    As an administrator/manager, what’s your current process for setting up and modifying workflow rules (triggers, automatons, macros, views)?
    We normally test and play with triggers and automations in Sandbox, then rebuild what works again in Production. We just build views and reports directly into Production. Macros are mostly used for defauling comment text, so we also just build those directly in production.

    If trigger or an automation just needs a tweak, we often just tweak it directly in Production. We do not keep Sandbox up-to-date. As a result, I do often have a rebuild the missing pieces in Sandbox manually before I can start build for a new project trigger or automation.

    If there is anything to test regarding emails - troubleshooting or setting up, this is always done in Sandbox first.


    Do you use the Zendesk Sandbox in this process and if so, what are the steps?
    1. Build in Sandbox. Rebuild and update any needed triggers or macros that don't already exist in Sandbox as necessary.
    2. Test in Sandbox. Login as different users to verify changes (agent, end user, light agent, etc.).
    3. Make changes in Sandbox as necessary
    4. Review with other teams as necessary for approval
    5. Rebuild in Production. It would be great to copy up to production for things that are built out well.


    What's working well? What's not working well?
    It's nice to have Sandbox and be able to play without affecting Production. However, things are named differently and we don't keep Sandbox up-to-date, so I often have to figure out what pieces I need and rebuild and update them before I start on a new project or work on troubleshooting an issue in Sandbox.


    What data do you need to be in the Sandbox for you to do this, and how do you get it there?
    Macros, Views, Triggers, Automation, forms, fields, field lists, roles. Extension too - but we have different test systems for extensions, so we do need to maintain those separately in Sandbox to connect to other sandboxes.


    What data is not there that you need?
    Macros, Views, Triggers, Automation, forms, fields, field lists, roles. I get this might be tricky since fields don't have the same IDs between environments - it would be nice to be able to map this so that we can make updates between environments.

    Also, it would be nice to have a way to see what other roles will see (like toggle my admin role) so I don't have to keep logging in as different users to trigger workflows and test results.


    Do you use the Sandbox for things other than making workflow changes?
    We've used it for demos to show new customers what to expect when they log into Zendesk and the end user portal and what emails will look like. We are all agents in Production, so there is no end user view for us to show new customers.

    0
  • Carlos Montoza
    Actions pour les commentaires Permalien

    I'll tell you directly how sandbox shall work.

    Once you click on the sandbox option right under admin, two columns: one to configure a new sandbox instance, the other to access the current instance.

    On the configure new sandbox column, there should be a checkbox for each feature: Triggers, automations, views, forms, conditional fields, dynamic content, etc.

    Just checking the features you want to replicate to the sandbox, and click on replicate.

    Once in the sandbox environment, for each trigger, automation, etc in its editing page a "go live" button to bring it to production.

    Any other option it's just pointless and wasting our time.

    2
  • Renée Gray
    Actions pour les commentaires Permalien

    I agree with Carlos 100%!

    0
  • Nicole - Community Manager
    Actions pour les commentaires Permalien

    Hi Renee, 

    Can you tell us more about the problem you would be trying to solve with these changes? How does it fit into your work flow? 

    0
  • Renée Gray
    Actions pour les commentaires Permalien

    I'm not sure I understand your question.  I believe all of your customers are facing the same issue.  We use Sandbox to create and test workflow and forms.  But we have not way to move those changes to production other than manually updating production which can lead to errors as well as causes extra work that is not necessary.  In the two previous CRMs I worked in, we never made changes in production. They were made in UAT, tested and the pushed to production.  Administrators only updated profiles in production.

    0
  • Dan Ross
    Actions pour les commentaires Permalien

    I like Carlos' idea of per-feature replication but I can see that being very complex and causing problems, as each feature may have dependencies on other parts of Zendesk.

    For example:  Triggers and Automations may have dependencies on Custom Fields, or on Target Extensions that would also need to be synced over. Without these existing first, the trigger would point to an empty value.
    Another example is that Conditional Fields may have requirements on Forms and Custom fields. I think it would be very difficult to pick and choose *exactly* what I'd want synced over, without running afoul of the Law of Unintended Consequences.

    That's not to say it's impossible, but given the choice, I'd rather have a sync that does everything and I *know* it's done everything, than a sync that has done certain things (and possibly others I don't know about or intend to sync).

    0
  • Shannon Anahata
    Actions pour les commentaires Permalien

    Hi all! I wanted to drop a quick intro to note that I am taking on the product management of our exploration into workflow changes, including Sandbox use cases. I'll be reviewing the google form linked in Kristen's official comment to set up interviews right away. Thanks for your patience here, and looking forward to connecting! 

    1
  • Mindaugas Verkys
    Actions pour les commentaires Permalien

    Possibility to auto-create and suspend agents from production to SB environment.

    For agents trainings should be great to start using SB and after switch them to Production. Also they should always have a possibility to make their tests in SB. Now if you don't reset the SB often forget who had access for SB and it's security issue for offboarding, and if you reset the SB and have hundred of agents it's impossible each time to re-create accounts for everyone. 

    Regards,

    0
  • Gerald Crawford
    Actions pour les commentaires Permalien

    We are not on the Enterprise level for usage yet...but since the Sandbox is only an option at the presumably higher volume utilization companies I would have to agree with many already mentioned.  A sandbox should be a staging site in which their production environment can be replicated and then changes made or implemented can be tested out before putting into a live environment.  

    SaaS companies have been doing this sort of thing for years.  The one thing you will need to ensure you can implement is a scrubbing of email addresses....or turn off SMTP on the stage environment all together.  No one wants to inadvertently email their customer simply because they changed something and their stage environment was live when it comes to email.

    0
  • Ryan Mumby
    Actions pour les commentaires Permalien

    As an administrator/manager, what’s your current process for setting up and modifying workflow rules (triggers, automations, macros, views)?

    Build any necessary components (fields, triggers, automations, macros, views) and manually input any conditions, actions, or data necessary to test. 

    Do you use the Zendesk Sandbox in this process and if so, what are the steps?

    Yes. First step is to go and take a look at everything in the sandbox thats could be related and manually check if it still matches production ( Since we can be testing several things at once this is not always the case). Next, I need to check if anything I'm testing is going to affect the testing our development team does for the integrations we've built via Zendesk API to our own platform.

    What's working well? What's not working well?

    Whats working well.... I guess the fact that there is a sandbox is better than none?

    Whats not...  It's an incredibly manual process thats super time consuming, and prone to human error. For starters, the only thing that copies over from production is the stuff that doesn't even matter. If the list of things that do and don't copy over were completely reversed, it would be much better.

    Also, not having any type of "Push to production" feature leaves the space for human error to mess something up when copying things from Sandbox to our Production environment.


    What data do you need to be in the Sandbox for you to do this, and how do you get it there?

    A selectable/configurable copying of

    • Templates (standard email, welcome email, and so on)
    • Settings (channels, agent permissions, and so on)
    • Administrators (names, identities, roles, and so on). Note that if any of the administrator account information is incorrect in your production environment, an error might appear.
    • Agents
    • Agent groups
    • Triggers, views, automations, macros, and targets
    • Custom ticket fields
    • Help Center content
    • Apps and integrations
    • Conditional fields

     


    What data is not there that you need?

    • Agents
    • Agent groups
    • Triggers, views, automations, macros, and targets
    • Custom ticket fields
    • Help Center content
    • Apps and integrations
    • Conditional fields

    Multiple Sandbox Instances (at least 2)

    Do you use the Sandbox for things other than making workflow changes?

    Testing API integrations between our own platform.

    Since we have to maintain a static testing environment for testing of our new product releases and the Zendesk API integrations, Being limited to one sandbox is very restrictive/nerve-racking for us. We're always worried that when we're testing Zendesk only improvements, we'll change something that inadvertently messes up the Zendesk API integration and causes delays in product releases/sprints/CABs for their team. Having the addition of another sandbox or more would be HUGE. Take a look at how Salesforce does this for an example of a better implementation.

     

    1
  • Massimo DiDio
    Actions pour les commentaires Permalien

    Guess there is enough evidence as to why we would love this option! Can we have now have it pretty please :-)

    1
  • Actions pour les commentaires Permalien

    Hey Massimo - 

    Good things take time, and we work in quarter-long sprints. But we'll keep you posted as things progress. 

    1

Vous devez vous connecter pour laisser un commentaire.

Réalisé par Zendesk