We have a number of Attendant profiles that are extremely large.   In an effort to streamline development of new features I'm looking at ways to import single menus within the profile, and I'm getting some odd results.

For example, one of our Profiles has and open and closed schedule.   The open schedule has 80 menus that we use to break the functionality up.   (labeled 4.1, 4.2, 4.3, etc.)      

I am seeing that if I package and export menu 4.6; when I delete node 4.6 and re-import the package any connection from 4.1-4.5 is lost.   The node will just have a blank space where it should have connected to something within 4.6.   Anything downstream of 4.6 updates the connections properly and works well.   

Currently if we have to update something I just package the entire profile and import it on the production servers, but this is problematic if we have multiple tickets in flight and one or more of them change or get pulled from our release.  Has anyone run into this issue, and is there an easy solution that I'm overlooking?  We are on CIC 2018 R2.
#Implementation

------------------------------
Josh Herron
------------------------------

Josh,

You have identified my biggest gripe with Interaction Attendant. Once you start using attendant for anything larger than a basic auto attendant menu administration becomes really difficult. This probably isn't helpful, and goes against what Genesys wants, but if my IVR is going to be more complicated than a couple menus deep I will build it in handlers and create subroutines to make changes easier.

Now that I got that out of the way I really only ever get packages to work if you package at the profile level. Furthermore It seems if you have ever copied and pasted anything within attendant all sorts of bad things happen in the profile if you try to export and import, this is one of the reasons why Genesys support will tell you to never copy stuff in attendant even though it supports it. Is it possible some of the menus you are trying to package up were copied at some time and this is why it is breaking the menu transfers? One last thing that has always bit me, when I try to work with really large attendants which have different schedules which have the same named menus I always run into issues where the source menu somehow references the wrong destination menu in another schedule.

You mention you have a ton of schedules, are these schedules just to play different up front messages but everything behind the schedule is the same? You could play your different message up front, then set an attribute if alternate routing is needed deeper in the flow, and then have all of the schedules dump into the same unified menu structure so you only need to change the menu in 1 spot.

Thanks,


------------------------------
Mark Tatera
ConvergeOne

Opinions are my own and not the views of my employer. Any suggestions or programming changes I suggest come with no warranty and should be tried at your own risk.
------------------------------

Original Message:
Sent: 01-10-2019 09:53
From: Josh Herron
Subject: Attendant node import tips

We have a number of Attendant profiles that are extremely large.   In an effort to streamline development of new features I'm looking at ways to import single menus within the profile, and I'm getting some odd results.

For example, one of our Profiles has and open and closed schedule.   The open schedule has 80 menus that we use to break the functionality up.   (labeled 4.1, 4.2, 4.3, etc.)

I am seeing that if I package and export menu 4.6; when I delete node 4.6 and re-import the package any connection from 4.1-4.5 is lost.   The node will just have a blank space where it should have connected to something within 4.6.   Anything downstream of 4.6 updates the connections properly and works well.

Currently if we have to update something I just package the entire profile and import it on the production servers, but this is problematic if we have multiple tickets in flight and one or more of them change or get pulled from our release.  Has anyone run into this issue, and is there an easy solution that I'm overlooking?  We are on CIC 2018 R2.
#Implementation

------------------------------
Josh Herron
------------------------------

I have had the same experience that Mark mentioned.  Packaging profiles only works for the least complex profiles.

------------------------------
Tim Cannon
Elevate Credit Services, LLC
------------------------------

Original Message:
Sent: 01-10-2019 10:41
From: Mark Tatera
Subject: Attendant node import tips

Josh,

You have identified my biggest gripe with Interaction Attendant. Once you start using attendant for anything larger than a basic auto attendant menu administration becomes really difficult. This probably isn't helpful, and goes against what Genesys wants, but if my IVR is going to be more complicated than a couple menus deep I will build it in handlers and create subroutines to make changes easier.

Now that I got that out of the way I really only ever get packages to work if you package at the profile level. Furthermore It seems if you have ever copied and pasted anything within attendant all sorts of bad things happen in the profile if you try to export and import, this is one of the reasons why Genesys support will tell you to never copy stuff in attendant even though it supports it. Is it possible some of the menus you are trying to package up were copied at some time and this is why it is breaking the menu transfers? One last thing that has always bit me, when I try to work with really large attendants which have different schedules which have the same named menus I always run into issues where the source menu somehow references the wrong destination menu in another schedule.

You mention you have a ton of schedules, are these schedules just to play different up front messages but everything behind the schedule is the same? You could play your different message up front, then set an attribute if alternate routing is needed deeper in the flow, and then have all of the schedules dump into the same unified menu structure so you only need to change the menu in 1 spot.

Thanks,


------------------------------
Mark Tatera
ConvergeOne

Opinions are my own and not the views of my employer. Any suggestions or programming changes I suggest come with no warranty and should be tried at your own risk.

Original Message:
Sent: 01-10-2019 09:53
From: Josh Herron
Subject: Attendant node import tips

We have a number of Attendant profiles that are extremely large.   In an effort to streamline development of new features I'm looking at ways to import single menus within the profile, and I'm getting some odd results.

For example, one of our Profiles has and open and closed schedule.   The open schedule has 80 menus that we use to break the functionality up.   (labeled 4.1, 4.2, 4.3, etc.)

I am seeing that if I package and export menu 4.6; when I delete node 4.6 and re-import the package any connection from 4.1-4.5 is lost.   The node will just have a blank space where it should have connected to something within 4.6.   Anything downstream of 4.6 updates the connections properly and works well.

Currently if we have to update something I just package the entire profile and import it on the production servers, but this is problematic if we have multiple tickets in flight and one or more of them change or get pulled from our release.  Has anyone run into this issue, and is there an easy solution that I'm overlooking?  We are on CIC 2018 R2.
#Implementation

------------------------------
Josh Herron
------------------------------

It is possible that the menus were copied, but I don't know for sure.   This deployment was originally started by ININ/Genesys and then finished by another vendor; at which point it was handed over to me.   I have maintained/updated this for the last few years and have done package exports from the profile level for our monthly releases without issue.   However, our company has adopted a more Agile development philosophy recently and now they want me to be able to start work on a story, and then set it aside for the future and switch to other work, which is problematic if my exports are at the profile level rather than at level of the menu I'm actually changing.

I'd like to spend some time and break each major function into it's own profile, but that would be a major undertaking and the preference is for me to work on new functionality vs optimization.

------------------------------
Josh Herron
------------------------------

Original Message:
Sent: 01-10-2019 10:41
From: Mark Tatera
Subject: Attendant node import tips

Josh,

You have identified my biggest gripe with Interaction Attendant. Once you start using attendant for anything larger than a basic auto attendant menu administration becomes really difficult. This probably isn't helpful, and goes against what Genesys wants, but if my IVR is going to be more complicated than a couple menus deep I will build it in handlers and create subroutines to make changes easier.

Now that I got that out of the way I really only ever get packages to work if you package at the profile level. Furthermore It seems if you have ever copied and pasted anything within attendant all sorts of bad things happen in the profile if you try to export and import, this is one of the reasons why Genesys support will tell you to never copy stuff in attendant even though it supports it. Is it possible some of the menus you are trying to package up were copied at some time and this is why it is breaking the menu transfers? One last thing that has always bit me, when I try to work with really large attendants which have different schedules which have the same named menus I always run into issues where the source menu somehow references the wrong destination menu in another schedule.

You mention you have a ton of schedules, are these schedules just to play different up front messages but everything behind the schedule is the same? You could play your different message up front, then set an attribute if alternate routing is needed deeper in the flow, and then have all of the schedules dump into the same unified menu structure so you only need to change the menu in 1 spot.

Thanks,


------------------------------
Mark Tatera
ConvergeOne

Opinions are my own and not the views of my employer. Any suggestions or programming changes I suggest come with no warranty and should be tried at your own risk.

Original Message:
Sent: 01-10-2019 09:53
From: Josh Herron
Subject: Attendant node import tips

We have a number of Attendant profiles that are extremely large.   In an effort to streamline development of new features I'm looking at ways to import single menus within the profile, and I'm getting some odd results.

For example, one of our Profiles has and open and closed schedule.   The open schedule has 80 menus that we use to break the functionality up.   (labeled 4.1, 4.2, 4.3, etc.)

I am seeing that if I package and export menu 4.6; when I delete node 4.6 and re-import the package any connection from 4.1-4.5 is lost.   The node will just have a blank space where it should have connected to something within 4.6.   Anything downstream of 4.6 updates the connections properly and works well.

Currently if we have to update something I just package the entire profile and import it on the production servers, but this is problematic if we have multiple tickets in flight and one or more of them change or get pulled from our release.  Has anyone run into this issue, and is there an easy solution that I'm overlooking?  We are on CIC 2018 R2.
#Implementation

------------------------------
Josh Herron
------------------------------