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
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
I love this change! Either I or (better) someone from my team would attend the call to discuss.