Call Flow Control

Alan, you could use tags which you can set per tenant to any string - and test in dialplan

there is no direct way to control these via feature codes though, so it may be something we could add in the future

Hi Alex,

Yep, key thing is that the end-user/customer can control it, so feature codes and/or via the customer web portal...

Alan.

A gui toggle switch for an "inbound route override " would rock ;)

How would you use the "override"? Also - there are already time based routes, operator managed, etc - how would you see this fit in the picture? Don't want to make this too complex as it is going to be potentially hard to support - i.e. user changed a setting and forgot, etc

A clean way would be to "mix in" conditions (like time condition, flag condition, custom condition, etc) into dialplan and inbound routes in particular, but it may be a bit late :)

I guess the way i saw it working would be similar to the Day/Night/Temp Officemode thats currently there, but adding a few more of those in... So then you can have a time-based route and an Officemode together...

The Call Flow Control feature in Freepbx is very good as you can have upto 10 and you can BLF them too... Nice thing about it is that during the day, some of my customers shut the office for an hour for lunch and they press the BLF button to forward calls to a pre-defined mobile number...

Mixing conditons would work great. Can this be done now? I dont see how I can specify a operator managed routed to go to a time condition route if "Day" and skip the time condition if set to "Night"

this can be done now by using a operator managed route that re-routes to another number setup as time based.

The purpose of day/night/temp is to fill the missing void of small businesses that wanted an exact replica of what they had. "i dont use an IVR, I have a live person answer the phone. And when she leaves at the end of the day I want her to be able to press a button on her phone... not use some fangled schedule" So complicating it with schedules could potentially undo its simplistic nature.

Erik,

I think the user's initial request is still highly valid as they were looking for additional variables not necessarily just to incorporate day/night/temp into the dialplan. Many other PBX management systems do support this as pointed out and there are a few use cases where this helps simplify the logic of the dialplan and allows you to create fewer routes and reroutes and time range groups and advanced scheduling.

As an example, I was just setting up a small business last week. They have a main IVR and their normal business hours are 8-6 where they have staff in the office. For the majority (90%+) of that time they have certain IVR options going to dedicated people, however, there is lunch and the very beginning and end of the day (8-830 and 530-6), where the dedicated person for 2 of the options is not in the office and the customer wanted all phones in the office to ring during those hours.

Without the option of multiple variables, the routing for this offered less flexibility than if multiple routing variables were available. Using day/night/temp and rerouting would not solve the problem as 2 different day/night/temp variables would essentially have been needed.

Rather than each one person department (for IVR purposes) being able to set that they were away at lunch/gone for the day, the times essentially had to be hard coded using schedules. This means if a person left for lunch later than the schedule and returned slightly later, the phones did not perform exactly as wanted. Additionally, vacation/sick days could not be properly handled.

Instead the only way we could implement this was to create 5 separate time ranges, one for 8-830, 12-1230 and 530-6, one for 830-1130, one for 1130-1200, one for 1230-1, one for 1 to 530, and one for when they are closed. This was needed because the lunch breaks were scheduled to be staggered by 30 minutes to allow only 30 minutes per day where they are overly short staffed. Between 1130-12, the person from one department is scheduled to be out while the other is there, and between 1230-1, the other person from the other department is gone, between 8-830, 12-1230, and 530-6 both are gone and hence only 1 time range group for those periods.

Now on my inbound route I need to create 5 different options, all routing to different IVRs that have different rules for each key press to handle the different strategies when the "department" is not staffed. Everything ends up hard coded to a specific schedule with no flexibility. If they want to staff extra on certain days do to an ad campaign, we need to go in and reprogram the entire schedule for those days. If someone calls in sick, the system either routes wrong or we need to adjust the routing again.

With multiple variable options and nesting, as described by the original poster, this could be accomplished with complete flexibility and customer control.

If 8-6 then:
if DeptA is active:
if DeptB is active:
Goto IVR with both active
else
Goto IVR with DeptA active
end if
else
if DeptB is active:
Goto IVR with DeptB active
else
Goto IVR with DeptA and DeptB NOT ACTIVE
end if
end if
else
Goto Closed
end if

Now the customer has complete control. Department A staff member can dial a feature code to set when they are there and away and modify the call control. Late lunch, no issue. Extra staff for 1 day, no issue. Department B staff member can have their own feature code to set their status as there or away and modify the call control.

Some will say, why not use call forwarding...2 reasons...

1. If the situation was a little more advanced and instead of an extension transfer for the IVR button, it was a hunt list that range that person first for 3 rings and then someone else, the hunt list wouldn't follow the forward and every caller would need to wait 4+ rings to be answered when the person was out.

2. The end user (in this case) didn't want callers that directly dialed an extension from the IVR to these particular personnel to be forwarded to the whole office, only the ones coming from the IVR.

Further, implementing such a system does not need to remove/replace the simple call routing options. You can simply add a third routing type and have time-based, operator-managed, and complex/hybrid (whatever new name you want to use routing).

in STE I would just do that in /etc/asterisk/user_extensions.include, technically you could do the same in MTE but I don't let people touch that in MTE. I still think the GUI will overly complicate it, and in the end, someone's going to complain that its still not enough variables. What you really need is a way to build dialplan logic where someone can just do and it insert it into another type of user_extensions.include, maybe one thats inside MySQL or one that publishes to an included file.

exten => s,1,NoOp(menuname)
exten => s,n,GoToIF(condition1 = value?context,exten,pri)
exten => s,n,GoToIF(condition2 = value?context,exten,pri)
exten => s,n,GoToIF(condition3 = value?context,exten,pri)
exten => s,n,SomeOtherCustomComands
exten => s,n,MacroExit

then you just need a custom inbound script that does a Goto for that menuname,s,1

Erik,

Needing to create custom scripts for each scenario essentially defeats the purpose of management system like Thirdlane/FreePBX/VoipNow/etc.

The GUI would not be overly complicated. This is a basic feature that is implemented in almost eery other PBX management system other than Thirdlane.

A quick browse of the forums shows exactly how many people want this feature by the numerous topics and replies started that all request essentially the same thing with different names for the same functionality.

If implemented properly and as described, there should be no complaints from someone wanting an additional variable as the system should be database driven and support an unlimited number of variables.

What other PBXs besides Free PBX have this feature?

Could someone give us access to a PBX that has this implemented?

Please send access info and instructions on how to see/try this feature to alex at thirdlane.com

Now that I looked at Free PBX I can see two applications with somewhat similar functionality - Time Conditions and Call Flow Toggle Control.

To the best of my understanding, Time Conditions are associated with time group otherwise they appear to be similar in 2 ways - they can be managed by calling a feature code and both of them define their destinations. The last is really horrible - it is against all the principles of engineering, is not reusable and makes it very difficult to trace the flow.

So, implementing Flow Control Toggle in a similar fashion (where it knows its destinations) would be a really bad idea, but adding this as another type of a step (Managed Flow Control) in inbound routes could probably work. While I am afraid this will be confusing for users, we could combine Time based and Operator Managed inbound routes, add "Managed Flow Control option (and allow user to select the type for each step) and call this something like Advanced Inbound Route. This would be similar to different types of steps in Huntlists.

Would this satisfy our former Free PBX users? :)

I think that would be great! It would be our responsibility as MTE admins & Resellers to educate end users to not use Managed Call Flows unless they really knew what they were doing, or maybe even have it disabled by default and enabled in System Preferences. But I don't think it would cause too much trouble if it was there. If people don't know what it is, they tend to avoid it. But it would also provide a solution for admins coming over from FreePBX & Elastix that are used to this sort of control with inbound routes.

Alex,

I think calling this feature "really horrible" and "against the principles of engineering" are extreme overstatements.

If implemented properly, the functionality can be "clean", reusable, and extremely flexible. The only true statement may be that depending on how complicated a user makes their call flow, the flow can potentially be difficult to trace. However, as mentioned by matt, I would expect that more complicated call flows would be programmed by more experienced users of asterisk/PBXs and therefore, those individuals would have the know how of how to trace the call path/flow no matter how complex it may become. Also, better users should be better at naming their variables/routes to make the flow easier to follow.

With that said, my vision of a complete implementation of this functionality that allows complete expandability and reusability while maintaining a clean interface and being as easy as possible for users to use is as follows:

For variable management:

1. A new option under "Routes" for "Call Flow Variables" (I personally think the Day/Night Mode Option belongs under Routes as well). Day/Night should stay independent from the call flow variables for less advanced users that need to retain the simplicity. As this would be a new option, it would also easily have its own permission option to be assigned to users to have access to them or not. The page should be DB driven and the user should be able to add/remove call flow variables and change their current settings with all variables having 3 modes just like day/night (true, false, and temp). Each new variable should have a unique DB ID which is the DB primary key. Like all things in MTE, these IDs may be prefixed by the tenant name so the numeric portion of the IDs do not increment too high (tenant1-101, tenant2-101, tenant1-102, tenant2-102).
2. A new script should be implemented for variable management that is similar to tl-set-daynight to be used by feature codes. The primary difference should be that instead of a static feature code, it should be used with a patterned feature code such as _*60. with the extra digits dialed being passed to the script as the call flow variable ID to be toggled (ie *60101 would trigger a toggle for variable id -101). The rest of the script functionality should essentially be the same. Instead of playback being day/night mode set, it should be true / false mode set and the variable name (as configured by the user in call flow variable config) read back using SayAlpha() asterisk application. In the interface, like other MTE features, the tenant name portion could be stripped from the display. For example, extensions are only displayed with their extension number, so in the call flow variable table, only 101, 102, 103, etc would be displayed in TL manager, even though behind the scenes the variables would be -101, -102, etc.

For Call Flow configuration:

1. A new option under "Routes" for "Custom Call Destinations". Again, as a new option, it should be easy to create a new permission option so that less advanced users can be restricted access to the feature by the system administrator. On this screen a user should be able to essentially create the equivalent of an inbound route but with a completely custom name that can be named by the user (as opposed to the standard inbound routes screen where the "route name"/descriptor is the DID/Pattern). The ONLY options for these routes should essentially be 4 options per route: the call flow variable to evaluate, and the 3 options for where to go when the variable is true, false, and temp. The options to show for the 3 variable conditions should be all of the scripts available to "inbound routes".
2. A new script should be created for "inbound routes" to redirect a call to a custom call destination. This would allow both nesting of call flow variables and a way to pass a call from the simple, existing thirdlane incoming call flow logic to the a complex call flow structure to be used and managed by more advanced users. Additionally, the separation of putting the options on different screens allows permissions to be defined to restrict access to these complex call routing features to more advanced users.

Examples of how this would work for the 2 specific requests/examples defined in this thread:

from awoodman example:

Steps to create flow with Thirdlane:

1. Create timerange group for 9am-5pm ("businesshours").
2. Create flow variable "FlowControl1_Variable".
3. Create flow variable "FlowControl2_Variable".
4. Create custom call destination called "FlowControl2". Define variable to evaluate as "FlowControl2_Variable". Define "true" option to run script "tl-reroute" and define the parameters of the script to reroute the call to the cell phone number you would like. Define "false" option to run script "tl-huntgroup" with the hunt group you wanted to run executed selected like any other "standard" inbound route would allow. Define temp, to whatever user wants.
5. Create custom call destination called "FlowControl1". Define variable to evaluate as "FlowControl2_Variable". Define "true" option to run script "Go to Voicemail" and a voicemail box selected like any other TL inbound route would allow you to select. Define "false" option to run script "tl-reroute-customdestination" (the new proposed script to reroute to a custom route destination) and in a dropdown box with all of the "custom call destinations" listed, select "FlowControl2". Define temp, to whatever user wants.
6. Create inbound route for DID using "Time Based Routes Group", defining route 1 to be when: "businesshours", run script "tl-reroute-customdestination", "FlowControl1" selected in dropdown. Define route 2 to be "anytime" and set it to use "Go to Voicemail" with the voicemail box selected like usual.

All done. Actual incoming call flow would be:

Call to DID -> Evaluates standard time based inbound route rules

then would branch:

if during businesshours -> goto "FlowControl1" which evaluates FlowControl1_Variable
-> if true -> Go to Voicemail
-> if false -> goto "FlowControl2" which evaluates FlowControl2_Variable
-> if true -> Reroute to Mobile
-> if false -> Go to Hunt Group
if not during business hours -> Go to Voicemail

from my example:

Steps to create flow with Thirdlane:

1. Create timerange group for 8am-6pm ("business hours")
2. Create flow variable "IsDeptAOpen".
3. Create flow variable "IsDeptBOpen".
4. Create custom call destination called "DeptBOpen_WhenDeptAOpen". Define variable to evaluate as "IsDeptBOpen". Define true option to run IVR script for DeptA Open and DeptB Open. Define false option to run IVR script for DeptA Open but Dept B closed. Define temp option as needed per customer requirement.
5. Create custom call destination called "DeptBOpen_WhenDeptAClosed". Define variable to evaluate as "IsDeptBOpen". Define true option to run IVR script for Dept A CLOSED and Dept B Open. Define false option to run IVR script for Dept A CLOSED AND Dept B CLOSED. Define temp as required.
6. Create custom call destination called "DeptAOpen". Define variable to evaluate as "IsDeptAOpen". Define true to run tl-reroute-customdestination with "DeptBOpen_WhenDeptAOpen" selected as the destination. Define false to run tl-rerote-customdestination with "DeptBOpen_WhenDeptAClosed". Define temp as required.
7. Create inbound route for DID using "Time Based Routes Group", defining route 1 to be when: "businesshours", run script "tl-reroute-customdestination", "DeptAOpen" selected in dropdown. Define route 2 to be "anytime" and set it to go to IVR for Business Closed.

All Done. Actual incoming call flow would be:

Call to DID -> Evaluates standard time based inbound route rules

then would branch:

if during businesshours -> goto DeptAOpen call destination -> evaluate IsDeptAOpen variable
-> if true -> goto DeptBOpen_WhenDeptAOpen call destination -> evaluate IsDeptBOpen
-> if true -> Goto IVR "DeptA_and_DeptB_Open"
-> if false -> Goto IVR "DeptA_Open_DeptB_Closed"
-> if false -> goto DeptBOpen_WhenDeptAClosed call destination -> evaluate IsDeptBOpen
-> if true -> Goto IVR "DeptA_Closed_DeptB_Open"
-> if false -> Goto IVR "DeptA_and_DeptB_Closed"
if not during business hours -> Goto IVR "Business_Closed"

Finally, if implemented in this manner, the "Custom call destination" functionality and script could be used in many in places to offer a much wider range of call routing flexibility to the Thirdlane system. IVRs could potentially use the custom call destination as another option to route IVR options based on call flow variables (for my example, this would simplify the configuration even further). Destination-no-answer options on hunt-lists could use this script as well for more advanced routing options (essentially like a completely new inbound call) if a hunt list time-outs.

I do not think when you break down the functionality in this manner that the routing is very difficult to configure nor layout in the Thirdlane system. The power and flexibility that such an implementation would offer is tremendous and would be a major step forward for Thirdlane.

The call routing examples did not stay formatted too well when posting to the forum. I attached my response as a txt file which makes it a bit easier to read and follows.

I hope I did not offend anyone - my opinion is about the implementation, not the feature.

As I convert from FreePBX, I can see points on both sides. Time Conditions with Destinations can be a very powerful feature, but also very cumbersome. There's been numerous times where I'd have this crazy complex order of Time Conditions for different DIDs. Then anytime there was an issue or a change was requested, I'd have to spend a bunch of time clicking through each Time Condition like following a trail of bread crumbs until I found what I was looking for. Whereas having a strict order in an inbound route in Thirdlane always gives me the overall trail of the route right in front of me. The downside being I can't create my complex time-sensitive route logic like before without creating a bunch of feature codes and fake DIDs.

Matt,

Your comment highlights the underlying issue and why complex call flow routing is NOT a bad thing. The alternative to accomplishing what you need the call flow to be (the fake DIDs and feature codes) is substantially more messy than a properly designed call destination type of call flow system. By separating the way I described, it keeps one level of functionality for 1 level of user and allows more complex routing for more advanced users.

Essentially, when looking at that 1 inbound route screen, while not perfect, you would get much more of an idea about where a route goes and what it does if you see a line that says go to destination "IsDeptAOpen" than you will from a reroute call to "5555555" or go to feature code *61443.

Another use case for advanced call flow and "call flow variables":

We had a customer contact us today because they lost internet at their office, but their PBX was hosted on our cloud platform so callers would still hear their IVR, but then calls would get stuck in queues and/or go right to voicemail. This obviously gives a negative appearance of the business, so they wanted incoming calls to change to simply play a message indicating that their phone lines were presently down and were expected to be repaired in 2-3 hours, please try calling back at that time (they were a large office, so rerouting to cell phones was not practical).

To accomplish, we had to modify their incoming route to route to the new message. While not a difficult change since they only had a single number, this could have been more of a required effort if they had 20 DIDs they used for different IVRs, etc.

If call flow variables were available, a variable for "OfficeAvailable" could be created and made a part of the call flow of several DIDs for larger offices that could be toggled in the event of loss of internet to change call routing across an entire organization with minimal effort.

As we are approaching renewal time for several of our customers....Is anything being done on this front in regards to more advanced call flow?

3CX has gone to an insanely flexible call flow model, however, in my opinion, it goes way beyond the needs of 90% of use cases and overly complicates things. This is another low hanging fruit for Thirdlane in my opinion to capture some market share by adding more flexibility as I outlined over 2 years ago while still keeping it simple for the average user.

https://www.3cx.com/docs/call-flow-designer-examples/