# Provisioning System Implementation Guidance

This page contains guidance for how to implement programmatic logic for automatically updating the Akixi Service configuration from Telephony Provider or Reseller provisioning systems.

# Cisco BroadWorks

# BroadWorks & Akixi Service Component Mappings

For Cisco BroadWorks® telephony platforms, there are effectively 3 component integration mapping strategies that can be employed for Akixi Service provisioning as listed below. One of these should be specifically selected as the integration scheme based on the size & type of Customers environments that are most likely to be deployed via the corresponding BroadWorks platform.

# Telephony Server Per BroadWorks Enterprise (Recommended)

The recommended approach is to create a separate Akixi Telephony Server entry per BroadWorks Enterprise component, and then create separate Partition elements for each individual BroadWorks Group (site) components. This approach is strongly suggested in order that the Akixi Partition level can be used as a scope permission assignment model for individual reporting supervisor Users, which might only require reporting privileges against a specific BroadWorks Enterprise Group.

This option requires BroadWorks read-only administrative API credentials to be created on the telephony platform at the Enterprise level, which are then set in the AuthUserID2, AuthPassword2, AuthUserID4 & AuthPassword4 properties accordingly.

Note

This Akixi Service component integration strategy has one limitation in that cross- BroadWorks-Group hunt groups & call centre queues can’t be supported (i.e. support for call distribution groups that contains extension user members across multiple BroadWorks Groups). If support for Enterprise-wide group distribution devices is required, then use option 2 or 3 instead accordingly.

Also

Cross-BroadWorks-Group calls are modelled as external calls, which means that reporting on “internal” calls made between extensions users in different BroadWorks Groups does not require an Akixi Device entry to be created for the remote extension user on the BroadWorks Group where separate Akixi Supervisor reporting may not actually be locally required for.

# Summary

Capability	Supported	Notes
Site Specific Reporting Permissions	✅	Akixi Reporting Supervisors can be easily restricted to only view single sites (BroadWorks Group components). Cross-Group calls are modelled as external calls, which means that reporting on “internal” calls made between extensions users in different BroadWorks Groups does not require an Akixi Device entry to be created for the remote extension user on the BroadWorks Group where separate Akixi Supervisor reporting may not actually be locally required for.
Enterprise-Wide Reporting	❌	Running individual Akixi reports across the entire enterprise is only supported when there are 5 Partitions or less.
Efficient Site License Usage	❌	Multiple Site Connection licenses are consumed for each Partition.
Clear API Usage Rules	✅	Whilst there are more Akixi components to programmatically create & maintain in this particular model, the mappings are logical & distinct. This makes it easier to create the required programmatic provisioning rules and determine the correct Akixi component identifiers to store within the external provisioning system logic.
Support For Enterprise-Wide Hunt Groups & Call Centre Queues	❌	Reporting for enterprise-wide hunt groups & call centre queues that contains extension user members across multiple BroadWorks Groups can’t be fully supported.

# Diagram

Individual Akixi Telephony Server components are mapped to separate BroadWorks Enterprises. Akixi Partition entries are created for each separate BroadWorks Group as required for site-specific reporting requirements.

Only calls made between extension users of the same Enterprise Group (i.e. intra-Group calls) are modelled by Akixi as internal calls (note that both Extension Devices involved within the corresponding call scenario must exist within the Akixi Service configuration in order for the call to be modelled at all). A separate external call is modelled within each Akixi Partition for calls made across Enterprise Groups (i.e. inter-Group calls). Calls between different BroadWorks Enterprises are modelled as a separate external call against each individual Enterprise. Calls to/from parties outside of the BroadWorks telephony platform are modelled as external calls.

Note thought that multiple Site Connection licenses are consumed for each Partition.

# Telephony Server Per BroadWorks Enterprise (Single Partition)

Similar to option 1 (Telephony Server Per BroadWorks Enterprise), but where only one Akixi Service Partition component is created which is associated with the entire BroadWorks Enterprise.

# Summary

Capability	Supported	Notes
Site Specific Reporting Permissions	❌	Akixi Reporting Supervisors cannot be easily configured to have permissions to only view single sites (BroadWorks Group components). It is also not easy for Reporting Supervisors to run reports on single sites, without carefully filtering reports by large sets of Devices, which is unwieldy.
Enterprise-Wide Reporting	✅	Running individual Akixi reports across the entire enterprise is supported.
Efficient Site License Usage	✅	Only one Site Connection license is utilised.
Clear API Usage Rules	❌	Whilst the high-level component mappings are straightforward in this particular arrangement, all “internal” calls made between extensions users in different BroadWorks Groups are only modelled if both users have a corresponding Device entry configured within the Akixi Service – this makes enabling internal call reporting more complicated & unwieldy to manage & support.
Support For Enterprise-Wide Hunt Groups & Call Centre Queues	✅	Reporting for enterprise-wide hunt groups & call centre queues is supported.

# Diagram

Individual Akixi Telephony Server components are still mapped to separate BroadWorks Enterprises. However one overall Akixi Partition entry is created for the whole Enterprise encompassing all BroadWorks Groups.

Calls made between any extension users of the same Enterprise are modelled by Akixi as internal calls (i.e. both inter-Group calls as well as inter-Group calls). Calls between different BroadWorks Enterprises are modelled as a separate external call against each individual Enterprise. Calls to/from parties outside of the BroadWorks telephony platform are modelled as external calls.

# Single Telephony Server

Conversely, a single Telephony Server entry can be configured instead that has BroadWorks System/Provisioning level API access, where individual Customer Enterprises are mapped to separate Partitions. This latter approach is easier to visualise as well as configure manually, but sacrifices the ability to allow BroadWorks Group specific organisation of sites within the Akixi Service as well as the easier facility for site-specific reporting permissions.

This option requires BroadWorks read-only administrative API credentials to be created on the telephony platform at the System or Provisioning level, which are then set in the AuthUserID2, AuthPassword2, AuthUserID4 & AuthPassword4 properties accordingly.

Note

Since one Akixi telephony platform communication session is rarely capable of supporting more than 100 Customer environments, a new Telephony Server component should be created when the number of Partitions mounted on an existing Akixi Telephony Server entry reaches a pessimistic safe limit of 80.

# Summary

Capability	Supported	Notes
Site Specific Reporting Permissions	❌	Akixi Reporting Supervisors cannot be easily configured to have permissions to only view single sites (BroadWorks Group components). It is also not easy for Reporting Supervisors to run reports on single sites, without carefully filtering reports by large sets of Devices, which is unwieldy.
Enterprise-Wide Reporting	✅	Running individual Akixi reports across the entire enterprise is supported.
Efficient Site License Usage	✅	Only one Site Connection license is utilised.
Clear API Usage Rules	❌	The dynamic management of how many Akixi Partitions are mounted on each Telephony Server component (particularly if Partitions are removed over time) makes this option more complicated to implement programmatically. Additionally, all “internal” calls made between extensions users in different BroadWorks Groups are only modelled if both users have a corresponding Device entry configured within the Akixi Service – this makes enabling internal call reporting more complicated & unwieldy to manage & support.
Support For Enterprise-Wide Hunt Groups & Call Centre Queues	✅	Reporting for enterprise-wide hunt groups & call centre queues is supported.

# Diagram

A single Telephony Server is created that is configured for System or Provisioning level BroadWorks API access, where individual Customer Enterprises are mapped to separate Partitions.

Calls are modelled identically as per the first integration option (“Telephony Server Per BroadWorks Enterprise (Multiple Partitions)”) when the Akixi Partition is mapped to an entire Enterprise; else as per the 2nd option when the corresponding Partition is associated directly to an BroadWorks Enterprise Group.

# Akixi Service Properties Stored Externally & New Provisioning Settings

Depending on the deployment model used, we suggest that various Akixi Service component identity values should be stored within the external provisioning system against its representation of the BroadWorks components indicated within the following table. In certain cases, new settings should be implemented against certain elements within the external provisioning system’s user interface that correlate to the corresponding component being created or deleted within the Akixi Service. However, developers/integrators may wish to implement different storage logic and/or value mappings based on their own specific requirements.

For diagnostic purposes, Akixi Service identity values stored within the external provisioning system should be ideally displayable somewhere in the system’s UI.

# Common Properties For All Integration Schemes

Akixi Component	Akixi Property	BroadWorks Component	Provisioning System UI Setting	Notes
Telephony Server	TelSysID	Enterprise	[Not Applicable]	The Property value should be stored against the system’s concept of BroadWorks Enterprise.
Extension Device	[None]	Extension User	Call Activity Monitored?	A new check box setting should be implemented against extension users that controls whether a corresponding Extension Device configuration entry is programmatically added (on) or deleted (off) within the Akixi Service. Setting the checkbox to off, should also automatically uncheck the ACD-related setting mentioned in the row below and automatically perform the Akixi ACD Agent entry deletion operation.
ACD Agent	[None]	Extension User (Agent)	ACD Agent Activity Monitored?	A new check box setting should be implemented against extension users that specifically have the Call Centre Standard or Premium BroadWorks license packs assigned to them. The new setting should control whether a corresponding ACD Agent configuration entry is programmatically added (on) or deleted (off) within the Akixi Service. Note that checkbox should not be enabled within the UI unless the first check box setting mentioned in the above row is already turned on.
Extension Device	IDOnTelSys	Extension User	BroadWorks UserID	An up-to-date BroadWorks UserID value must be maintained against existing Akixi Device entries.
ACD Agent	IDOnTelSys	Extension User (Agent)	BroadWorks UserID	An up-to-date BroadWorks UserID value must be maintained against existing Akixi ACD Agent entries.
Application User	ReportingAccess	Extension User	Akixi Reporting Supervisor Type	A new drop-down combo box style setting implemented against extension users. When the UI setting’s value is a valid Akixi reporting supervisor type, then this should automatically cause a corresponding Akixi Application User entry to be programmatically created.
Application User	Username EmailAddr	Extension User	E-mail Address	The extension user’s assigned e-mail address (not the BroadWorks UserID) should be used as the username & e-mail delivery address against the Akixi Application User.
Application User	Password PasswordChgRequired (Optional) SendWelcomeEmail (Optional) LockOut (Optional)	Extension User	Generate New Default Password	A new checkbox setting should be implemented, which when ticked on, automatically generates a new secure random password against the corresponding Akixi Application User and also forces the Akixi user to have to change their password on next successful sign-in, as well as unlock the user if they were previously locked-out. The setting should also only be editable (enabled) when the previously mentioned “Akixi Reporting Supervisor Type” setting is configured to be a valid Akixi reporting supervisor type.

# Telephony Server Per BroadWorks Enterprise (Multiple Partitions)

Akixi Component	Akixi Property	BroadWorks Component	Provisioning System UI Setting	Notes
Partition	PartIDInTelSys	Group	[Not Applicable]	The Property value should be stored against the system’s concept of BroadWorks Enterprise Group
Partition	LicensedForRptUserType	Group	Akixi Reporting Site License	A new drop-down combo box style setting implemented against the system’s concept of BroadWorks Enterprise Group. When the UI setting’s value is a valid Akixi site license, then this should automatically cause the Akixi Telephony Server component to be programmatically created (or made/asserted to be in-service if it already exists), and then similarly the Partition component to be created or made in- service as well.
Application User	PartIDInTelSys – Permissions Container	Extension User	Akixi Reporting Supervisor Enterprise- Wide Permissions?	A new check box setting should be implemented against extension users that is editable (enabled) only when the previously mentioned “Akixi Reporting Supervisor Type” setting is configured to be a valid Akixi reporting supervisor type. When the check box is turned on, then the corresponding Application User should be configured for reporting scope permissions on any Partition, whereas when unchecked (off), the Application Users’ Partition scope permissions Property should be specifically set to the Partition component associated with the corresponding extension user’s owning BroadWorks Group.

# Telephony Server Per BroadWorks Enterprise (Single Partition)

Akixi Component	Akixi Property	BroadWorks Component	Provisioning System UI Setting	Notes
Partition	PartIDInTelSys	Enterprise	[Not Applicable]	The Property value should be stored against the system’s concept of BroadWorks Enterprise.
Partition	LicensedForRptUserType	Enterprise	Akixi Reporting Site License	A new drop-down combo box style setting implemented against the system’s concept of BroadWorks Enterprise. When the UI setting’s value is a valid Akixi site license, then this should automatically cause the Akixi Telephony Server component to be programmatically created (or made/asserted to be in-service if it already exists), and then similarly one dedicated Partition component to be created or made in-service as well.

# Single Telephony Server

Akixi Component	Akixi Property	BroadWorks Component	Provisioning System UI Setting	Notes
Partition	PartIDInTelSys	Enterprise	[Not Applicable]	The Property value should be stored against the system’s concept of BroadWorks Enterprise.
Partition	LicensedForRptUserType	Enterprise	Akixi Reporting Site License	A new drop-down combo box style setting implemented against the system’s concept of BroadWorks Enterprise. When the UI setting’s value is a valid Akixi site license, then this should automatically cause the Akixi Telephony Server component to be programmatically created (or made/asserted to be in-service if it already exists), and then similarly one dedicated Partition component to be created or made in-service as well.

# Provisioning System User Interface Options

# Akixi Reporting Site License Settings

The following wireframe diagrams illustrate some suggestions for where to implement the Akixi site license setting within an existing provisioning system, for the various component mapping schemes.

# Telephony Server Per BroadWorks Enterprise (Multiple Partitions)

The following diagram provides suggestions for how the Akixi site-level license settings should look in a hypothetical Business IP telephony provisioning system.

# Telephony Server Per BroadWorks Enterprise (Single Partition)

The diagram below suggests how the Akixi site-level license settings should look for the 2nd integration scheme.

# Single Telephony Server

The suggested UI options would be similar to that shown in the above mapping scheme (one Akixi Telephony Service & single Partition per BroadWorks Enterprise).

# Akixi Reporting Extension Level Settings

The following diagram provides suggestions for how the Akixi Reporting settings should look at the BroadWorks extension-user equivalent level within a hypothetical Business IP telephony provisioning system. These would be the same when using any of the three Akixi Service to BroadWorks component mapping options, apart for the “Enterprise-Wide Permissions:” setting which wouldn’t be visible for integration options 2 & 3.

Note that all of these Akixi-related settings should be dimmed (and not editable) when no Reporting Site License is assigned against the owning Customer environment.

Note

The above diagram shows Akixi Application Users (Reporting Supervisors) effectively being optionally created & associated with BroadWorks extension users. This is only one suggestion - it may not be satisfactory for all Customer environments that require several “Wallboard screen” type Application Users to be created for the specific purpose of running Desktop Wallboard reports for use on smart TVs. In such cases, the corresponding Akixi “Wallboard” Reporting Supervisor may not necessarily be logically associated with any particular BroadWorks extension user, plus usually such supervisors have an appropriate Akixi username of something like wallboard1.headoffice@globalbankcorp.com, as opposed to an e-mail of a real person with a physical phone endpoint.

An alternative suggestion is to have a specific UI area dedicated to configuring multiple Akixi Application Users at the provisioning system’s BroadWorks Group or Enterprise level, although this would obviously be more work to implement for developers/integrators.

# Provisioning System Use Cases

This sub-section provides examples of some basic BroadWorks provisioning system use-cases, which indicate the suggested Akixi Service component model modifications to programmatically make in each particular case using flow diagrams. Additionally, some use-cases also require BroadWorks administration credentials to be created in order to make the BroadWorks CTI & OCI- P API integrations work correctly between the Akixi Service and the designated BroadWorks platform.

Note that similar to the previous recommendations for the new user interface options within the provisioning system, any guidance given is only in the form of suggestions, where developers/integrators may wish to implement different logic based on their own specific requirements. Additionally, this sub-section shouldn’t be considered as a fully inclusive & comprehensive set of rules to follow & implement – these use-cases are provided in order to help implementers/developers fully consider & contemplate their own required usage scenarios as well as plan for the required cross-system data tracking & invocation logic.

# Akixi Reporting Site License Enabled And/Or Changed

This is when the Akixi Reporting site license setting is turned on or changed for an entire Customer telephony environment within the external provisioning system, either at the BroadWorks Group level (integration scheme 1) or at the BroadWorks Enterprise level (integration schemes 2 & 3).

# A1 Akixi Reporting Site License Changed

The Akixi Reporting Site license setting is changed within the external provisioning system and the new value reflects that Akixi Reporting is enabled against the corresponding Customer environment.

# A2 Does The Provisioning System Have An Existing TelSysID?

The external provisioning system should detect if it already has a stored TelSysID value, indicating whether it has previously created an Akixi Telephony Server component.

# A3 Does The Akixi Telephony Server Exist?

If the external provisioning system already has a stored TelSysID value, then it should use a TelSysInfo request to verify that the corresponding Akixi Telephony Server component actually exists.

# B1 Create BroadWorks Administrator

If the external provisioning system has not previously created the required Akixi Telephony Server entry, then it should first create BroadWorks administrator credentials at the appropriate BroadWorks component level (System or Provisioning level for integration scheme 3, and Enterprise level for schemes 1 & 2).

# B2 Create Akixi Telephony Server

A TelSysAdd request should be used to programmatically add a new Akixi Telephony Server entry, setting the AuthUserID2, AuthPassword2, AuthUserID4 & AuthPassword4 Properties accordingly to the previously created BroadWorks administrator credentials. Various other Properties should also be configured correctly such as the TelSysType, CMEnvironmentID

Parameter Name	Usage Context	Parameter Type	Description
CMEnvironmentID	TelSysAdd TelSysChange TelSysInfo	String	The CMEnvironmentID Property is the unique identifier of a CM environment which the telephony server must be associated with. Any emails that are sent with regards to the telephony server will use the email connectivity settings of the chosen CM Environment domain profile.

IPAddrOrHost1, IPAddrOrHost2, IPAddrOrHost3, IPAddrOrHost4, TCPPort2, TCPPort4, UseSSLTLS2, UseSSLTLS4, CommsParameter1, & CommsParameter2 settings. It is strongly recommended to specifically set the value of the TelSysID Property when programmatically creating new Telephony Server components via external provisioning or billing systems. Most Telephony Providers or Aggregators with a dedicated Akixi Service URL will have their own Akixi-assigned start range for TelSysID values, which they should automatically self-track & increment internally within their own automated system(s). To find out the starting range of your TelSysID Property, sign into your Akixi Service via the web interface and view the last existing Telephony Server entry that has already been manually pre-created, either as a demonstration simulator environment, a hosted platform lab test connectivity test, or for actual live Customer environments. Then add 1 to this value.

# B3 Make Akixi Telephony Server In-Service

If a previous Akixi Telephony Server component exists, then based on the result of the TelSysInfo request, the corresponding component should be placed in-service by setting its CommsEnabled Property to True via a TelSysChange operation if the value was previously set to False.

# C1 Does The Provisioning System Have An Existing PartIDInTelSys?

The external provisioning system should detect if it already has a stored PartIDInTelSys value, indicating whether it has previously created an Akixi Partition component.

# C2 Does The Akixi Partition Component Exist?

If the external provisioning system already has a stored PartIDInTelSys value, then it should use a PartitionInfo request to verify that the corresponding Akixi Partition component actually exists.

# D1 Create Akixi Partition

A PartitionAdd request should be used to programmatically add a new Akixi Partition entry, setting the IDOnTelSysOwner Property to the corresponding BroadWorks EnterpriseID. For integration scheme 1, the IDOnTelSys Property should also set to the corresponding BroadWorks Enterprise GroupID.

# D2 Make Akixi Partition In-Service

If a previous Akixi Partition component exists, then based on the result of the PartitionInfo request, the corresponding component should be placed in-service by setting its CommsEnabled Property to True via a PartitionChange operation if the value was previously set to False.

# E1 Enable Akixi Application Users

All Akixi Application Users associated with the corresponding Customer environment should be “enabled” by setting their ReportingAccess Property to the current provisioning system’s stored Reporting Supervisor Type value, via a UserChange operation.

Note that for integration scheme 1, only Application Users associated with the corresponding BroadWorks Group should be “enabled”, whereas for schemes 2 & 3, all Application Users associated with the entire BroadWorks Enterprise should be “enabled” instead.

# Akixi Reporting Site License Disabled

This case occurs when the Akixi Reporting site license is turned off for an entire Customer telephony environment within the external provisioning system, either at the BroadWorks Group level (integration scheme 1) or at the BroadWorks Enterprise level (integration schemes 2 & 3). Note that the step shown in red should only be performed for integration scheme 2.

# A1 Akixi Reporting Site License Changed

The Akixi Reporting Site license setting is changed within the external provisioning system and the new value reflects that Akixi Reporting is specifically turned off against the corresponding Customer environment.

# C1 Make Akixi Partition Out-Of-Service

The corresponding Akixi Service Partition component should be placed out-of-service by setting its CommsEnabled Property to False via a PartitionChange operation.

# C2 Make Akixi Telephony Server In-Service

Specifically only for integration scheme 2, the associated Akixi Telephony Server component should also be placed out-of-service by setting its CommsEnabled Property to False via a TelSysChange operation.

# D1 Disable Akixi Application Users

All Akixi Application Users associated with the corresponding Customer environment should be disabled by setting their ReportingAccess Property to “None” via a UserChange operation. The copy of this setting within the external provisioning system should not be changed, and should still reflect the old reporting supervisor type value, in order that the Akixi User accounts can be reinstated if the site license is subsequently re-enabled.

Note that for integration scheme 1, only Application Users associated with the corresponding BroadWorks Group should be disabled, whereas for schemes 2 & 3, all Application Users associated with the entire BroadWorks Enterprise should be disabled instead.

# BroadWorks Extension User Enabled For Akixi Call Report Monitoring

This is when the “Call Activity Monitored” setting is specifically checked on within the external provisioning system against a BroadWorks extension user.

# A1 “Call Activity Monitored” Setting Checked On

The “Call Activity Monitored” setting is checked on against an extension user within the external provisioning system.

# A2 Automatically Undim “ACD Agent Monitored” Setting

The “ACD Agent Monitored” setting within the external provisioning system should be subsequently shown undimmed (enabled but unchecked) within the provisioning system’s user interface, but only if the corresponding BroadWorks extension user has the Standard or Premium Call Centre license packs applied to them.

# B1 Does A Matching Akixi Device Configuration Entry Already Exist?

The provisioning system should determine whether an existing Akixi Service Device entry exists that matches the corresponding extension user. However, the Akixi Service internally indexes its Device configuration entries by DeviceNumber Property, where its value should be constructed using specific rules based on the main public number & internal dialling configuration against the corresponding device within the underlying BroadWorks telephony platform. Additionally, the DeviceNumber Property is automatically adjusted via the Akixi Service Partition synchronisation logic, as public number and/or internal dialling address assignment changes are detected within the underlying BroadWorks telephony. Therefore when obtaining Akixi Device entries via the Web Services API, there is the potential for the Akixi Service configuration to be slightly out-of-date versus the provisioning system, when matching entities based on numbering information, which could have just recently changed within BroadWorks and/or the external provisioning system.

Accordingly to mitigate such scenarios, a matching Akixi Device should be searched for by specifically performing a complete DeviceList operation for the associated Partition, and then verifying whether any of the returned Devices have a BroadWorks UserID value within the returned IDOnTelSys Property matching the corresponding extension user.

# C1 Create Akixi Extension Device Entry

A new Akixi Service extension Device entry should be created using a Chat Integration Parameters.

Parameter Name	LiveChat Chat Integration	Chat Simulator Integration
IDOnChatSys	✅	✅

Certain parameters must be set to appropriate values based on the chat integration type as described below:

Parameter Name	Integration Type	Requirements
IDOnChatSys	LiveChat	[Not Implemented yet.]
IDOnChatSys	Chat Simulator	A chat ID for the group device within the simulated omnichannel contact centre. Note that a group must have a non-empty value configured for this Property, in addition to its ChatIntegrationEntry Property being specified as “Chat Simulator”, in order for it to distribute virtual chats within the simulator.

# E-mail Integration Parameters

Parameter Name	POP3 & SMTP	E-mail Simulator
EmailSysUserID	✅	❌
EmailSysPassword	✅	❌
EmailSysEmailAddress	✅	✅
IDOnEmailSys	❌	❌

Certain parameters must be set to appropriate values based on the e-mail integration type as described below:

Parameter Name	Integration Type	Requirements
EmailSysUserID	POP3 & SMTP	The username that will be used to establish POP3 & SMTP protocol communications with the group device’s corresponding mailbox on the associated e-mail server.
EmailSysPassword	POP3 & SMTP	The password that will be used to establish POP3 & SMTP protocol communications with the group device’s corresponding mailbox on the associated e-mail server.
EmailSysEmailAddress	POP3 & SMTP	The e-mail address of the group mailbox in the external e-mail server, which will be used when sending e-mails from this group.
EmailSysEmailAddress	E-mail Simulator	An e-mail address for the group device within the simulated omnichannel contact centre. Note that a group must have a non-empty value configured for this Property, in addition to its EmailIntegrationEntry Property being specified as “E-mail Simulator”, in order for it to distribute virtual e-mails within the simulator.

DeviceAdd operation. An appropriately “mangled” DeviceNumber Property value (based on the corresponding extension user’s main public & internal numbering assignments) should be given, a DeviceType Property of “Extension”, as well as all the other required Properties as specified within sub-section “Device Request Parameters”.

# D1 Update Akixi Device Entry

If an existing Akixi Service Device entry was previously found with a matching BroadWorks UserID within its IDOnTelSys Property, then the existing Device entry should be updated via a DeviceChange operation. The DeviceType Property should be set to “Extension”, as well as all the other required Properties as specified within sub-section “Device Request Parameters”.

# BroadWorks Extension User Disabled For Akixi Call Report Monitoring

This case occurs when the “Call Activity Monitored” setting is specifically checked off within the external provisioning system against a BroadWorks extension user.

# A1 “Call Activity Monitored” Setting Checked Off

The “Call Activity Monitored” setting is checked off against an extension user within the external provisioning system.

# A2 Automatically Turn Off “ACD Agent Monitored” Setting

The “ACD Agent Monitored” setting within the external provisioning system should be automatically updated and made unchecked (i.e. turned off). Additionally the setting should be subsequently shown dimmed (disabled) within the provisioning system’s user interface.

# B1 Does A Matching Akixi Device Configuration Entry Already Exist?

A matching Akixi Device should be searched for by specifically performing a complete DeviceList operation for the associated Partition, and then verifying whether any of the returned Devices have a BroadWorks UserID value within the returned IDOnTelSys Property matching the corresponding extension user.

# B2 Delete Akixi Device Entry

The existing Akixi Service Device entry should be deleted using a DeviceDelete operation.

# C1 Does A Matching Akixi ACD Agent Configuration Entry Already Exist?

A matching Akixi Agent should be searched for by specifically performing a complete ACDAgentList operation for the associated Partition, and then verifying whether any of the returned Agents have a BroadWorks UserID value within the returned IDOnTelSys Property matching the corresponding extension user.

# C2 Delete Akixi ACD Agent Entry

The existing Akixi Service ACD Agent entry should be deleted using an ACDAgentDelete operation.

# BroadWorks Extension User Configured For Call Centre Working

This occurs when any operation performed within the external provisioning system culminates in a BroadWorks extension user having either the Standard or Premium Call Centre license packs applied to them, where before the operation neither one was previously applied at all. Note that the application of the Basic Call Centre license pack should not be considered in this scenario and can effectively be ignored.

# A1 Standard Or Premium License Pack Applied

An extension user within the external provisioning system is updated to have either the Standard or Premium Call Centre license packs applied to them.

# A2 Automatically Undim “ACD Agent Monitored” Setting

The “ACD Agent Activity Monitored” setting within the external provisioning system should be subsequently shown undimmed (enabled but unchecked) within the provisioning system’s user interface, but only when the “Call Activity Monitored” setting is currently checked on.

# BroadWorks Extension User Removed From Call Centre Working

This case occurs when any operation performed within the external provisioning system culminates in a BroadWorks extension user having neither Standard nor Premium Call Centre license packs applied to them, where before the operation one or both of them was/were previously applied. Note that the application of the Basic Call Centre license pack should not be considered in this scenario and can effectively be ignored.

# A1 Standard/Premium License Packs Removed

An extension user within the external provisioning system is updated to have neither Standard nor Premium Call Centre license packs applied to them.

# A2 Automatically Dim “ACD Agent Monitored” Setting

The “ACD Agent Activity Monitored” setting within the external provisioning system should be subsequently shown dimmed (disabled) within the provisioning system’s user interface.

# B1 Does A Matching Akixi ACD Agent Configuration Entry Already Exist?

# B2 Delete Akixi ACD Agent Entry

The existing Akixi Service ACD Agent entry should be deleted using an ACDAgentDelete operation.

# BroadWorks Extension User Enabled For Akixi ACD Agent Report Monitoring

This is when the “ACD Agent Activity Monitored” setting is specifically checked on within the external provisioning system against a BroadWorks extension user.

# A1 “ACD Agent Activity Monitored” Setting Checked On

The “ACD Agent Activity Monitored” setting is checked on against an extension user within the external provisioning system.

# B1 Does A Matching Akixi ACD Agent Configuration Entry Already Exist?

A matching Akixi ACD Agent should be searched for by specifically performing a complete ACDAgentList operation for the associated Partition, and then verifying whether any of the returned Agents have a BroadWorks UserID value within the returned IDOnTelSys Property matching the corresponding extension user.

# C1 Create Akixi ACD Agent Entry

A new Akixi Service ACD Agent entry should be created using Chat Integration Parameters

Parameter Name	LiveChat Chat Integration	Chat Simulator Integration
IDOnChatSys	✅	✅

Certain parameters must be set to appropriate values based on the chat integration type as described below:

Parameter Name	Integration Type	Requirements
IDOnChatSys	LiveChat	[Not Implemented yet.]
IDOnChatSys	Chat Simulator	A chat ID for the agent within the simulated omnichannel contact centre. Note that an agent must have a non-empty value configured for this Property, in addition to its ChatIntegrationType Property being specified as “Chat Simulator”, in order for it to handle virtual chats within the simulator.

# E-mail Integration Parameters

Parameter Name	POP3 & SMTP	E-mail Simulator
EmailSysEmailAddress	✅	✅
IDOnEmailSys	❌	❌

Certain parameters must be set to appropriate values based on the e-mail integration type as described below:

Parameter Name	Integration Type	Requirements
EmailSysEmailAddress	POP3 & SMTP	The e-mail address that the agent will use to receive and send omnichannel e-mail contact items. Note that an agent must have a non-empty value configured for this Property, in addition to its EmailIntegrationType Property being specified as “POP3 SMTP”.
EmailSysEmailAddress	E-mail Simulator	An e-mail address for the agent within the simulated omnichannel contact centre. Note that an agent must have a non-empty value configured for this Property, in addition to its EmailIntegrationType Property being specified as “E-mail Simulator”, in order for it to handle virtual e-mails within the simulator.

ACDAgentAdd operation. An appropriately “mangled” AgentNumber Property value (based on the corresponding extension user’s main public & internal numbering assignments) should be given, as well as all the other required Properties as specified within sub-section “ACD Agent Request Parameters”.

# D1 Update Akixi Device Entry

If an existing Akixi Service ACD Agent entry was previously found with a matching BroadWorks UserID within its IDOnTelSys Property, then the existing Agent entry should be updated via an ACDAgentChange operation. All the required Properties as specified within sub- section “ACD Agent Request Parameters” should be updated accordingly.

# BroadWorks Extension User Disabled For Akixi ACD Agent Report Monitoring

This case occurs when the “ACD Agent Activity Monitored” setting is specifically checked off within the external provisioning system against a BroadWorks extension user.

# A1 “ACD Agent Activity Monitored” Setting Checked Off

The “ACD Agent Activity Monitored” setting is checked off against an extension user within the external provisioning system.

# B1 Does A Matching Akixi ACD Agent Configuration Entry Already Exist?

# B2 Delete Akixi ACD Agent Entry

The existing Akixi Service ACD Agent entry should be deleted using an ACDAgentDelete operation.

# BroadWorks Extension User’s UserID Changed

This case covers the scenario when the BroadWorks UserID value is changed against an extension user, which should be propagated to the corresponding Akixi Service Device & ACD Agent entries accordingly as appropriate.

# A1 BroadWorks UserID Changes Against Extension User

The BroadWorks UserID values is changed against an extension user within the external provisioning system.

# B1 Does A Matching Akixi Device Configuration Entry Already Exist?

A matching Akixi Device entry should be searched for by specifically performing a complete DeviceList operation for the associated Partition, and then verifying whether any of the returned Devices have the old (previous) BroadWorks UserID value within the returned IDOnTelSys Property matching the corresponding extension user.

# B2 Update Existing Akixi Device Entry

The existing Akixi Service Device entry should be updated using a DeviceChange operation, where the IDOnTelSys Property is set to the new BroadWorks UserID value.

# C1 Does A Matching Akixi ACD Agent Configuration Entry Already Exist?

A matching Akixi Agent should be searched for by specifically performing a complete ACDAgentList operation for the associated Partition, and then verifying whether any of the returned Agents have the old (previous) BroadWorks UserID value within the returned IDOnTelSys Property matching the corresponding extension user.

# C2 Update Existing Akixi ACD Agent Entry

The existing Akixi Service ACD Agent entry should be updated using an ACDAgentChange operation, where the IDOnTelSys Property is set to the new BroadWorks UserID value.

# BroadWorks Extension User & Virtual Subscriber Modifications

This covers multiple provisioning system update scenarios that can be automatically detected by the “light” Akixi Service Partition synchronisation mechanism, which should be subsequently invoked afterwards programmatically, in order that the corresponding changes can correctly be reflected within the Akixi Service configuration. To learn more about the Akixi Service synchronisation feature, refer to sub-heading “Partition Configuration Synchronisation”.

The relevant external provisioning system update scenarios are listed below:

# New Virtual Subscribers Added

The addition of any virtual BroadWorks Subscriber such as hunt groups, page groups, instant- call groups, call pickup groups, call centre queues, voice messaging devices, automated attendants, meet-me conferencing bridges, etc.

# Membership Changes To Distribution Devices

Membership changes made for any virtual subscriber that acts as a “distribution” mechanism. This includes hunt groups, page groups, instant-call groups, and call centre queues.

# BroadWorks UserID Changes To Any Virtual Subscriber

Changes made to the main BroadWorks UserID value associated with any virtual subscriber itself.

# Assigned Public Number Against BroadWorks Groups

Whenever the public number changes that is assigned to a BroadWorks Enterprise Group within its Profile“Calling Line ID Group Number” setting.

# Numbering Changes On Any Subscriber

Any numbering assignment change made for extension users or virtual subscribers. This includes changes to the “Phone Number” or “Extension” fields under a subscriber’s BroadWorks ProfileAddresses settings area, Alternative Number configuration changes, and DNIS numbering changes for call centre queues.

# Description Changes To Any Device

Changes made to the “main” description against any subscriber. Note that for extension users this is any change made to the corresponding subscriber’s “First Name” or “Last Name” settings, whereas for virtual subscribers it is changes made to their single Description or Name field.

# Code Changes

Any additions or changes made to ACD Unavailable, Account/Authorisation, and Disposition codes.

A flow diagram representing the required actions for all these scenarios is shown below:

# A1 Affecting Provisioning System Change Made

One of the previously mentioned provisioning system update scenarios is performed.

# C1 Does The Provisioning System Have An Existing PartIDInTelSys?

The external provisioning system should detect if it has an associated PartIDInTelSys value stored against the owning Customer telephony environment that the affecting configuration change was made within. This is used to detect whether the provisioning system has previously created an Akixi Partition component. As previously mentioned, for integration scheme 1, the PartIDInTelSys value should be stored by the provisioning system at the BroadWorks Group component level, but for integration schemes 2 & 3 it is stored at the BroadWorks Enterprise component level.

# C2 Does The Akixi Partition Component Exist?

# D1 Perform Akixi Partition Synchronisation

If the Akixi Partition component exists, then a “light” configuration synchronisation should be invoked for it. A PartitionChange request should be submitted giving a SyncNow Property value of True. Note that an SyncType Property value must be specified with the value ‘1’ (“Soft”), otherwise a full configuration synchronisation operation would potentially be performed instead that would automatically add all Extension & ACD Agent entries to the Akixi Service configuration, which would in turn immediately affect monthly billing charges without them being solicited from human interaction via the external provisioning system.

# Akixi Reporting Supervisor Type Setting Changed

This case occurs when the Akixi Reporting Supervisor Type setting is changed against an extension user within the external provisioning system. Note that the step shown in red should only be performed for integration scheme 1.

# A1 Reporting Supervisor Setting Changed

The “Reporting Supervisor Type” setting is changed against an extension user within the external provisioning system.

# B1 Does A Matching Akixi Application User Entry Already Exist?

A matching Akixi Application User entry should be searched for by specifically performing a UserInfo operation with the Username Property given as the e-mail address assigned to the corresponding extension user.

# C1 Create New Akixi Application User Entry

A new Akixi Service Application User entry should be created using a UserAdd operation.

Both Username & EmailAddr Properties should be set to the e-mail address configured against the corresponding extension user. The FullName Property should be set to the concatenation of the extension user’s “First Name” and “Last Name” settings with a space character added in-between. A temporary random & secure password should be set via the Password Property, and the PasswordChgRequired Property also set True to force the Akixi User to change their password on first sign-in. If sending “new reporting user” Welcome E- mails isn’t implemented within the provisioning system, then the SendWelcomeEmail Property can be set True, which instructs the Akixi Service to send a Welcome E-mail message for the new User instead.

The external provisioning system is likely to have existing logic already that is capable of generating secure, random, and cryptographically strong (non-deterministic) password values. However, if such logic needs to be introduced from scratch, a type 4 (securely pseudo randomly generated) UUID generated via a java.util.UUID.randomUUID equivalent mechanism is a possible suggestion, although UUID values tend to be quite unwieldy for first- time users to handle. Alternatively, a shorter 8-12 character randomly generated text value could be generated via an equivalent of the Apache Commons org.apache.commons.lang.RandomStringUtils library, although the use of its static method that provides an argument for the supplied source of randomness, thus allowing a cryptographically unpredictable source to be specified (e.g. java.security.SecureRandom), is recommended. Note that integrators/developers must assess & evaluate the specific usage, suitability, and vulnerabilities of the specific library(s) & library versions variants employed themselves, as we make no guarantee that these suggested routes are appropriate or secure.

The ReportingAccess Property should be set based on the Akixi Reporting Supervisor Type setting value actually changed to.

Finally the User’s Permissions & Endpoint container Properties should be configured accordingly. For all integration schemes, the TelSysID – Permissions Container Property should be provided. For integration scheme 1, the PartIDInTelSys – Permissions Container Property should also be specified – this should be set to a value of “All” when the “Enterprise-Wide Permissions” setting is checked on, and when unchecked, the Property should be set to the associated PartIDInTelSys value stored against the owning Customer telephony environment that the affecting Reporting Supervisor Type configuration change was made within. Similarly, the TelSysID – Endpoint Container Property should be provided, although the PartIDInTelSys – Endpoint Container Property should always be specified as the associated PartIDInTelSys value stored against the owning Customer telephony environment.

If the “Call Activity Monitored” setting is turned on for the corresponding extension user then the DeviceNumber – Endpoint Container Property should also be provided to set the User’s extension location in order to allow them to do call control actions within certain Akixi real-time reports. Note that determining the DeviceNumber value of the underlying Akixi Device entry matching the corresponding extension user, actually requires a DeviceList operation to be submitted for the associated Partition, and then verifying whether any of the returned Devices have a BroadWorks UserID value within the returned IDOnTelSys Property matching the corresponding extension user. These steps are not shown in the above flow diagram.

The DeviceNumber – Permissions Container, AgentNumber – Permissions Container, and AgentNumber – Endpoint Container Properties should not be set for all integration schemes.

# D1 Update Akixi Application User Entry

If an existing Akixi Service Application User entry was previously found with a matching e-mail address within its Username Property, then the existing User should be updated via a UserChange operation. The ReportingAccess Property should be set accordingly based on the Akixi Reporting Supervisor Type setting value actually changed to.

# E1 Enable/Disable Enterprise-Wide Permissions Setting

This step is only performed in integration scheme 1. If the “Reporting Supervisor Type” option is set to “None”, then the “Enterprise-Wide Permissions” setting should be dimmed (disabled), else the setting should be shown enabled (editable).

# Akixi Reporting Supervisor Enterprise-Wide Setting Changed

This scenario only occurs in integration scheme 1, when the Akixi reporting supervisor “Enterprise- Wide Permissions” setting is changed value against an extension user within the external provisioning system.

# A1 Enterprise-Wide Setting Changed

The reporting supervisor “Enterprise-Wide Permissions” setting is changed against an extension user within the external provisioning system.

# B1 Update Akixi Application User Entry

The existing Application User should be updated via a UserChange operation where the user is identified by specifying the extension user’s e-mail address within the Username Property. The PartIDInTelSys – Permissions Container Property should be appropriately updated based on the value of the “Enterprise-Wide Permissions” setting. A value of “All” should be used when the “Enterprise-Wide” setting is checked on, and when unchecked, the Property should be set to the associated PartIDInTelSys value stored against the owning Customer telephony environment that the configuration change was made within.

# New Password Generated For Akixi Reporting Supervisor

This scenario is when the “Generate New Default Password” setting is checked-on within the external provisioning system and the Apply button is clicked. A new random password should be generated for the corresponding Akixi Application User, and then the “Generate New Default Password” setting should be automatically unchecked as it shouldn’t be persisted anywhere and only exists in order to allow both the corresponding User to potentially be unlocked (if locked out), as well as new password credentials to be generated for them.

# A1 New Password Option Checked On & Applied

The “Generate New Default Password” setting is checked-on within the external provisioning system and the Apply button is clicked.

# A2 Update Akixi Application User Entry

The existing Akixi Application User should be updated via a UserChange operation where the User is identified by specifying a Username Property matching the e-mail address assigned to the corresponding extension user. A temporary random & secure password should be set via the Password Property, and the PasswordChgRequired Property also set True to force the User to change their password on first sign-in. If sending “new reporting user” Welcome E- mails isn’t implemented within the provisioning system, then the SendWelcomeEmail Property can be set True, which instructs the Akixi Service to send a Welcome E-mail message for the new User instead.

As previously mentioned, the external provisioning system is likely to have existing logic already that is capable of generating secure, random, and cryptographically strong (non- deterministic) password values. However, if such logic needs to be introduced from scratch, a type 4 (securely pseudo randomly generated) UUID generated via a java.util.UUID.randomUUID equivalent mechanism is a possible suggestion, although UUID values tend to be quite unwieldy for first-time users to handle. Alternatively, a shorter 8-12 character randomly generated text value could be generated via an equivalent of the Apache Commons org.apache.commons.lang.RandomStringUtils library, although the use of its static method that provides an argument for the supplied source of randomness, thus allowing a cryptographically unpredictable source to be specified (e.g.java.security.SecureRandom), is recommended. Note that integrators/developers must assess & evaluate the specific usage, suitability, and vulnerabilities of the specific library(s) & library versions variants employed themselves, as we make no guarantee that these suggested routes are appropriate or secure.

# BroadWorks Extension User E-mail Address Changed

This use case covers the scenario where the e-mail address against an extension user is modified, and the change is propagated to the corresponding Akixi Application User if previously created. However, currently this scenario is not fully supported within the Akixi Web Services API without deleting the existing Application User and then recreating it from scratch. Unfortunately this has the detrimental effect of resetting the report configuration for the corresponding Akixi reporting supervisor User, where any previous report additions and/or changes made would be lost forever. Therefore, we would also encourage developers/integrators to show a warning confirmation within the provisioning system, whenever e-mail address changes are being made for extension users which have an associated Akixi reporting supervisor account.

# A1 Extension User E-mail Address Changed

The e-mail address setting is changed against an extension user within the external provisioning system.

# B1 Does A Matching Akixi Application User Entry Already Exist?

# C1 Delete Existing Akixi Application User Entry

If an existing Akixi Service Application User entry was previously found with a matching e-mail address within its Username Property, then the existing user should be delete via a UserDelete operation.

# D1 Create New Akixi Application User Entry

A brand-new Akixi Service Application User entry should be created using a UserAdd operation.

Both Username & EmailAddr Properties should be set to the e-mail address configured against the corresponding extension user. The FullName Property should be set to the concatenation of the extension user’s “First Name” and “Last Name” settings with a space character added in-between. A temporary random & secure password should be set via the Password Property, and the PasswordChgRequired Property also set True to force the User to change their password on first sign-in. If sending “new reporting user” Welcome E-mails isn’t implemented within the provisioning system, then the SendWelcomeEmail Property can be set True, which instructs the Akixi Service to send a Welcome E-mail message for the new User instead.

As mentioned previously, the external provisioning system is likely to have existing logic already that is capable of generating secure, random, and cryptographically strong (non- deterministic) password values. However, if such logic needs to be introduced from scratch, a type 4 (securely pseudo randomly generated) UUID generated via a java.util.UUID.randomUUID equivalent mechanism is a possible suggestion, although UUID values tend to be quite unwieldy for first-time users to handle. Alternatively, a shorter 8-12 character randomly generated text value could be generated via an equivalent of the Apache Commons org.apache.commons.lang.RandomStringUtils library, although the use of its static method that provides an argument for the supplied source of randomness, thus allowing a cryptographically unpredictable source to be specified (e.g. java.security.SecureRandom), is recommended. Note that integrators/developers must assess & evaluate the specific usage, suitability, and vulnerabilities of the specific library(s) & library versions variants employed themselves, as we make no guarantee that these suggested routes are appropriate or secure.

The ReportingAccess Property should be set based on the Akixi Reporting Supervisor Type setting value actually changed to.

Finally the User’s Permissions & Endpoint container Properties should be configured accordingly. For all integration schemes, the TelSysID – Permissions Container Property should be provided. For integration scheme 1, the PartIDInTelSys – Permissions Container Property should also be specified – this should be set to a value of “All” when the “Enterprise-Wide Permissions” setting is checked on, and when unchecked, the Property should be set to the associated PartIDInTelSys value stored against the owning Customer telephony environment that the affecting Reporting Supervisor Type configuration change was made within. Similarly, the TelSysID – Endpoint Container Property should be provided, although the PartIDInTelSys – Endpoint Container Property should always be specified as the associated PartIDInTelSys value stored against the owning Customer telephony environment.

The DeviceNumber – Permissions Container, AgentNumber – Permissions Container, and AgentNumber – Endpoint Container Properties should not be set for all integration schemes.

← Error Codes Developing Client Applications →