Improve the development lifecycle for engagements

Related products: PX Engagements

Trying to do iterative development on engagements is very painful and time consuming, especially when you enable triggering them from the KC Bot. Anyone with a rudimentary exposure to software development lifecycles knows that you should never work directly on what’s in production. Since there’s no real versioning or branching support, you end up cloning active engagements and the active KC Bot, changing the audience criteria and working on the new version.

Working on the clones is also painful, as you need to constantly pause the Dev Bot or remove the engagement from it, then pause the engagement and then work on it.

 

Actually, if you have the engagement open before you pause the bot, it will keep complaining it’s being used in an active bot, even if you have since paused it. The engagement doesn’t refresh the bot’s state after every attempt to pause the engagement. The opposite happens when you work on a bot, to add an engagement. It doesn’t refresh the engagement state, when you try to enable it after previously pausing it. In both cases, you need to go back to the list of engagements or bots and reopen it. 

 

After you do all that, you hit the next snag. Preview mode is fine, but you really want to see the thing published in prod, so that coworkers without access to or knowledge of Gainsight can evaluate and provide feedback (call it QA). So you need to keep publishing changes to your dev version. The issue here is that you’re never really sure how long it will take for someone to see the new version of the bot or engagement. Sometimes it’s a few seconds, others it’s minutes and sometimes you need to clear all cookies or start a session in incognito.

 

I don’t know the internal limitations of your solution, but I do know that you need a better way to support quick iterations, probably via some kind of versioning or branching system. Perhaps that system would be combined with the ability to launch an engagement to staging, i.e. a control of which version/branch goes to staging vs which one is visible in production.

 

The FE warnings that I can’t edit X because it’s used in Y need to be replaced with an automation that protects the system, without adding unnecessary overhead to the user. e.g. when you tell me that it’s used in an active KC Bot, ask me if I want to pause the bot or remove the engagement from it, something better than the current process.

Video showing steps needed to make some simple changes when a engagement is in a KC bot.


Yes, it’s very painful to update engagements that are in a launched KC bot! 


To further complicate development, we ran into the situation where an engagement was pulled into multiple KC bots. However, if there are many KC bots in a tag, there is no easy way to see which KC bot includes that engagement. One of my colleagues submitted a separate RFE for that improvement: https://community.gainsight.com/ideas/identify-bot-for-an-engagement-44733


@cakrit  - Just now stumbled onto this, but I had also posed an idea of a full-blown release train.   The current setup is really prohibitive for quick iterations and a dev-to-prod lifecycle.   I also can’t imagine that the back-end of the engagements is much more than XML or YAML → I would think this would be something that could be done in some type of git-based flow (which would also fulfill your idea on versioning and return to a previous state).  

 

@jmobley 


Hi All

We heard you all loud and clear. This has been an area we have been working on to simplify and I am glad to let you know we are working towards a early May release. We plan to introduce a new state for Engagements in which user need not remove the engagement for making the edits. A Draft version for Engagements if you will. Happy to setup some time and discuss on this if you would want to partner with us on this design and usecase. I will try and post a early recording of this on the thread as we get closer to the finish line.

As ever, thanks again for being part of this “ Together journey”.

Regards

 


No StatusIN DEVELOPMENT

I  love this change!  Either I or (better) someone from my team would attend the call to discuss.


@skalle  - I’ve been using the “drafts” functionality quite a bit to make changes to the live/published engagement content.   I’m noticing that if I'm trying to test the edits after publishing, it can sometimes be difficult to know if I’m looking at the old versus the new version of the engagement.   Ideally, it would be nice if you showed some type of “version” in the engagement editor (like v1, v2, v3) and then also hid this as some type of CSS Selector (version=v1) in the engagement displayed in the product.  This way, I could launch the dev tools in the browser to inspect the engagement and validate that I’m looking at the updated engagement before getting a few screens in and seeing the change isn’t live yet because the guide is still the old version.