7Configuring Advanced Communications Features

Configuring Advanced Communications Features

This chapter provides information about advanced configuration for communications features, primarily for session communications. It includes the following topics:

• Using Macro Expansion for Character Fields

• Working with Dialing Filters

• Configuring Telesets for Hoteling

• Configuring Multitenancy

• Configuring Communications Login and Logout

• Configuring Remote Transfers and Conferences

• Using the Push Keep Alive Driver for Session Connections

• Using Business Services with Siebel Communications Server

• Integrating with Siebel Scripting Languages

• Integrating with Siebel SmartScript

• Integrating with the Customer Dashboard

• Viewing Communications Status Data

Using Macro Expansion for Character Fields

Some parameter values for events or commands, communications drivers, or configuration parameters can contain macro-expansion characters, which allow the actual values of those fields to be calculated based on contextual data such as the current business component or other run-time data.

This topic contains the following information:

• Macro-Expansion Syntax Elements

• Macros for Parameter Values

• Macro Expansion with Phone Numbers

• Work Item Attributes

• Macro-Expansion Examples

Macro-Expansion Syntax Elements

Macro expansion uses the following syntax elements:

• Brackets ([ ]) can contain a field name from the record that is currently selected in the Siebel application, for example, a record displayed in a dialog box. Brackets are applicable to event and command parameters only.

• Braces ({ }) can contain a field name from the current business object, business component, work item, or session data, or can contain one of the macros described in Macros for Parameter Values. The Communications Server processes the content of braces after executing a pop-up applet. This applies to command data only.

• A colon (:) following a field name functions as a separator to introduce modifying keywords, attributes, subfields, or numeric ranges that determine what data to extract and substitute. For information about how this element is used in phone number processing, see Macro Expansion with Phone Numbers.

• A backslash (\) functions as an escape character, allowing you to place a literal bracket, brace, or colon in a value without its being subject to macro expansion.

Macros for Parameter Values

Several macros (sometimes referred to as special fields) can be used within values for applicable event or command parameters, configuration parameters, or, in limited cases, driver parameters.

Note: Unless otherwise stated, you cannot use the macros described in this topic within values for communications driver parameters.

When the parameter value is read into memory (such as when the event or command is invoked), particular values are substituted for the macro name. These macros are not specific to any particular communications system, such as a specific CTI middleware product.

Some macros require work item attributes to be provided. Notations for specifying attributes are shown in examples. For more information, see Work Item Attributes.

Event attributes are also available for use in parameter values that support macro expansion. For example, the event attribute SiebelChannelType represents the channel type of the current work item. For more information, see Driver Event Attributes.

The macros that start with the at sign (@) are static variables with values that are defined at run time (values for some of these macros might change during a user session). The macros that start with the dollar sign ($) are actually functions that return a value. The macros, which have names that start with the at sign (@) or the dollar sign ($), are listed as follows:

• @ACDDNList. The list of ACD DNs (extensions of type A) associated with the current agent.

  The values are separated by commas.

• @AgentId. Agent login for the current agent.

• @AgentPin. Password for the agent login for the current agent.

• @ClientHostName. Host name of the agent’s computer. This value might be incorrect if the requirements for hoteling are not met (using Destkop Integration Siebel Agent), as described in Configuring Telesets for Hoteling.

• @ClientIP. IP address of the agent’s computer. As with @ClientHostName, the value of @ClientIP might be incorrect if the requirements for hoteling are not met (using Destkop Integration Siebel Agent), as described in Configuring Telesets for Hoteling

• @Configuration. The current configuration for the agent.

• @CountryCode. The country code applicable to the agent’s location.

  If the agent’s country is the U.S., then this macro returns an empty value. If the agent’s country is other than the U.S., then the macro returns the applicable country code, preceded by a plus (+). For example, if the agent’s country is France, then the macro returns +33.

• @DeselectedWorkItem. The item in the Work Items list in the communications toolbar that had the focus just prior to the item that currently has the focus. (The item with the focus is represented by the @SelectedWorkItem macro.) This macro must be specified with an attribute value, as follows:

  @DeselectedWorkItem:attribute_name

  where attribute_name is the work item attribute that you are providing. For more information, see Work Item Attributes.

• $DialingRuleMethod. Used within parameter values for the DialingFilter.RuleN configuration parameters, this macro calls a custom business service method to determine how to translate phone numbers when the dialing filter is in effect.

  The custom business service must recognize the input arguments Filter and PhoneNumber. Filter is the filter in effect for the parameter that invokes the macro. PhoneNumber is the number that needs to be translated. For example, for the following dialing rule, Filter is 650:

  DialingFilter.Rule2 = "650->$DialingRuleMethod(myservice.mymethod)"

  The business service must also support an output parameter called PhoneNumber. For example, if your dialing filter rule is to be applied to the U.S. number [phone], where numbers with prefix 123 in the area code (650) must be changed to use prefix 555, then the business service method might return the PhoneNumber output parameter with the value 916505554567.

  After a dialing filter rule is applied that uses the macro $DialingRuleMethod, no other filters are applied.

  For more information about using this macro with dialing filters, see Working with Dialing Filters.

• @DNList. The list of DNs (standard extensions of type S) associated with the current agent.

  The values are separated by commas.

• @EditControl. The data in the edit field (text box) control in the communications toolbar.

  This macro yields a value only when the edit field in the communications toolbar has the focus and contains a value. Use @EditControl when agents input values other than phone numbers into the communications toolbar’s edit field, such as to log in to the switch.

• $GetCommandStatus. Obtains the status of the device command for a communications command. Possible status values returned are:

  • Checked. The command is in toggled-down state, and the button displays (for example, if the agent indicates Not Ready for new work items, then the button is toggled down).

  • Blinking. The command is available, and the button is blinking.

  • Enabled. The command is available, and the button is enabled.

    Note: You can use this macro within command parameters, but not within event parameters. Events cannot use this macro to determine the status of a device command.

• Disabled. The command is not available, and the button is disabled.

  You can obtain the command status with an expression like this:

  $GetCommandStatus(device_command)

  where device_command is the name of the device command for the command. For example, a command parameter to determine the status of the device command might be defined as follows:

  FilterSpec = "[$GetCommandStatus(ChangeNotReadyState)]='Checked'"

  In this case, if the status of ChangeNotReadyState is Checked, then FilterSpec matches, and the command containing this FilterSpec parameter can execute.

• $GetInboundWorkItemAttr. Obtains the attributes of an inbound work item.

  You can obtain the work item attributes with an expression like this:

  $GetInboundWorkItemAttr(channel_name, attribute_name)

  where channel_name is the name of the locale-independent channel for the work item, and attribute_name is the work item attribute that you are interested in. For example, a command data parameter to obtain the tracking ID of an inbound voice work item might be defined as follows:

  Param.TrackID = "{$GetInboundWorkItemAttr(Voice, DriverWorkTrackID)}"

  For more information, see Work Item Attributes.

• $GetWorkItemAttr. Obtains the attributes of a work item, for example, in an event handler evaluating a new work item, or in a command.

  You can obtain the work item attributes with an expression like this:

  $GetWorkItemAttr(workitem_ID, attribute_name)

  where workitem_ID is the ID number of the work item, if known, and attribute_name is the work item attribute that you are interested in.

  For example, an event handler parameter to verify that the ContactId attribute (a custom work item attribute) has a value might be defined as follows:

  FilterSpec = "[$GetWorkItemAttr(SiebelWorkItemID, ContactId)] IS NOT NULL"

  For commands operating on the selected work item, you can also obtain work item attributes using @SelectedWorkItem:attribute_name.

  For more information, see Work Item Attributes. For more information about the SiebelWorkItemID attribute, see Driver Event Attributes.

• $HotelingPhone. Retrieves an agent’s extension if the agent is using a hoteling teleset. The field value is calculated at run time according to these rules:

  • Uses the login name of the currently selected agent (employee), or the name of a service request owner, to find the agent’s run-time extension, if the agent is using a hoteling teleset. In the first example following, Login Name is the Login Name field of the current business component, which corresponds to the LOGIN column in the S_USER table.

  • If the extension is not found, then $HotelingPhone retrieves the employee’s extension number from the S_USER table.

  The following example parameter definition in a make-call command (command data definition) might generate the extension that you want, based on the Login Name field:

  Param.PhoneNumber = "{$HotelingPhone(Login Name):Lookup}"

  Alternatively, the following example parameter definition for a make-call command might generate the extension that you want, based on the Owner field. Use a parameter value like this for a command invoked when the current business component is Service Request, to call the owner of the current service request record.

  Param.PhoneNumber = "{$HotelingPhone(Owner):Lookup}"

  For more information, see Configuring Telesets for Hoteling.

• @Language. The language code applicable to the agent’s Siebel application session. For example, the language code for U.S. English is ENU.

• @Now. Returns the current timestamp, using the following format:

  %month/%day/%Year %H:%M:%S

• @Phone. Represents a phone number, whose value is calculated at run time according to these rules:

  • If the Phone # field in the communications toolbar has the focus and contains a value, then @Phone is equal to the value of this field.

  • If the Phone # field has no value, but the currently active applet field is of the type DTYPE_PHONE, then @Phone is equal to the value of this field.

  • If the Phone # field has no value and the currently active field is not of the type DTYPE_PHONE, then @Phone is equal to the value of the field referred to by the Primary Phone Field user property for the business component.

  In all other cases, the @Phone macro contains no data. For more information, see Macro Expansion with Phone Numbers.

• @PrimaryQueueList. The list of ACD queues associated with the agent and designated as primary. For example, a login command might include a parameter like this to identify which ACD queues to log the agent into:

  Param.ACDQueue = "{@PrimaryQueueList}"

  The values are separated by commas.

• @QueueId. The list of ACD queues associated with the agent and designated as primary.

  Note: @PrimaryQueueList replaces @QueueId, but you can still use @QueueId for compatibility purposes.

• @QueueList. The list of ACD queues associated with the agent. This list includes all such queues, including those marked as primary and those not marked as primary. The values are separated by commas.

• @Random. A string containing 10 random digits. You can use this macro for testing purposes.

• $RemoteConnectStr. The name of the remote call center. This macro, which you can use with transfers and conference calls between call centers, derives the name of a remote call center’s communications configuration from either:

  • The ConnectString configuration parameter (if defined), or

  • The extension number of the agent to be called

  For example, a command parameter in a transfer or conference command might generate the configuration name in this fashion:

  Param.RemoteConnectStr = "[$RemoteConnectStr(@Phone)]"

  For more information, see Configuring Remote Transfers and Conferences.

• $RemoteConnectStr2. The name of the remote call center. This macro, which you can use with transfers and conference calls between call centers, derives the name of a remote call center’s communications configuration from either:

  • The ConnectString configuration parameter (if defined), or

  • The employee ID of the agent to be called

  For example, where the SelectBusObj and SelectBusComp parameters are set to Employee, a command parameter in a transfer or conference command might generate the configuration name in this fashion:

  Param.RemoteConnectStr = "[$RemoteConnectStr2(Id)]"

  The Employee business component uses the Id field to uniquely identify an employee record. A command that references another business component might have to use another field name to uniquely identify a record. For more information, see Configuring Remote Transfers and Conferences.

• @SelectedDN. The currently selected extension in the Communications options of the User Preferences screen.

• @SelectedQueue. The currently selected ACD queue record in the Agent Queues list in the Communications options of the User Preferences screen.

• @SelectedText. Text the user has selected in the browser, such as in a field in an applet within the Siebel application. The text might be used, for example, to provide a phone number to call or to provide some other input data for a command.

• @SelectedWorkItem. The item in the Work Items list in the communications toolbar that has the focus. (The item that had the focus just prior to this item is represented by the @DeselectedWorkItem macro.) This macro must be specified with an attribute value, as follows:

  @SelectedWorkItem:attribute_name

  where attribute_name is the work item attribute that you are providing. For more information, see Work Item Attributes.

• @UserId. Siebel login ID of the current Siebel user.

• @UserName. Login name of the current Siebel user.

• @UIPhone. The phone number that the agent clicked. See also the description of the communications parameter CallFromUICommand, in Parameters for Communications Configurations.

• @WorkDuration. Length of time, in seconds, of the current work item. That is, the time elapsed since the work item started.

• @WorkObjectID. Row ID of the work-item tracking object that was transferred to the agent or that was created as a result of creating an event log and defining a value for the AfterWork event log parameter.

• @WorkStartTime. Date and time (timestamp) when the work item arrived or was initiated. The timestamp is in the following format:

  %month/%day/%year %H:%M:%S

@Phone Macro Example

The example command and associated command data shown in the following table and second table in this topic use the @Phone macro, which you can use to dial any phone field on any business component.

Table Command: Make Call ToCurrentPhone

Parameter Name	Parameter Value
Description	Make Call to "{@Phone}"
DeviceCommand	MakeCall
Hidden	True

The following table shows a command data definition for this command definition.

Table Command Data: MakeCallToCurrentPhone

Parameter Name	Parameter Value
AttachContext	True
Param.CallNotifyText	Call from {@UserName}...
Param.PhoneNumber	{@Phone:PhoneTypeLookup}
RequiredField.@Phone	?*

Macro Expansion with Phone Numbers

Macro expansion provides many options for retrieving and manipulating phone number data for use with communications events or commands. This topic applies to event and command parameters only.

The macro @Phone is often used to retrieve a phone number; for a detailed description of this macro and its encoded logic, see Macros for Parameter Values. Alternatively, you can explicitly specify the name of a field from which to extract phone number data.

Note: When you work with phone number fields in event and command parameter definitions, you must be aware of how phone number data is formatted in your deployment of the Siebel Business Applications and of the implications of the formatting. Dialing filters must be specifically designed and implemented to accommodate local requirements for transforming phone number data from the stored format. For phone number data stored in fields using the DTYPE_PHONE data type, when matching phone number data through QuerySpec or QuerySpec2 event response functions, you might have to use LIKE rather than = (equals) in predicate clauses.

For information about phone number formatting, including formatting for international numbers, see Siebel Applications Administration Guide.

You can use the following special macro-expansion features when retrieving phone number data:

• A keyword to specify how to apply dialing filters to the field value. For more information about the keywords, see Keywords to Specify Dialing-Filter Behavior.

• A keyword to indicate the part of the phone number that you want to extract. For more information about the keywords, see Keywords to Extract Part of a Phone Number.

• A specific range of numerals to extract from the field value. For more information about the ranges, see Numeric Ranges to Extract.

Keywords to Specify Dialing-Filter Behavior

Follow the field name with a colon (:) and one of the following keywords to specify whether to filter the field data using dialing filter rules specified using DialingFilter.RuleN configuration parameters. Dialing filters are applied in numeric sequence until a match is found.

Dialing filter rules allow you to perform an intelligent translation of a phone number, in order to optimize dialing. You can use the macro $DialingRuleMethod within a dialing filter rule definition to invoke a business service method to specify custom logic in the application of the dialing filter rule to the results.

You can use the following keywords with either the @Phone macro or a field whose name you explicitly specify:

• Lookup. Applies the dialing filters to the field data.

  You can use Lookup with fields that you know to contain phone number data that can be successfully filtered with your dialing filters.

• PhoneTypeLookup. Checks if a field is of type DTYPE_PHONE (as defined in Siebel Tools). If it is of this type, then the dialing filters are applied to the field data. If it is not of this type, then the dialing filters are not applied to the field data.

Caution: In order for phone number data to be handled correctly in your application, do not modify the type for any field defined as DTYPE_PHONE.

For examples, see Macro-Expansion Examples. For more information about DialingFilter.RuleN configuration parameters, see Specifying Parameters for a Communications Configuration.

Keywords to Extract Part of a Phone Number

Follow a field name with a colon (:) and one of the following keywords to specify the portion of the phone number field to be extracted and substituted. You can use these keywords only with fields of type DTYPE_PHONE. If none of these keywords is specified after a field name, then the phone number from the field corresponds to IntlNumber. IntlNumber can also be specified explicitly.

Note: The plus sign (+) is included only in the value for IntlNumber, when this keyword represents an international number. In the following keyword descriptions, references to the country code do not include the plus sign (+) character.

• IntlNumber. Represents one of the following:

  • If the country code for the number matches the current locale for the Siebel Server (Application Object Manager), then IntlNumber represents the domestic phone number (number without the country code or extension).

  • If the country code for the number does not match the current locale for the Siebel Server (Application Object Manager), then IntlNumber represents the international phone number (+ and country code and number, without the extension).

• Digits. The full phone number as stored in the database field (country code, phone number, and extension).

• Country. The country code only (without the phone number or extension).

• Number. The phone number only (without the country code or extension).

• Extension. The phone number extension only (without the country code and phone number). This keyword is applicable when the phone number field contains an extension number prefaced with an x or another localized character).

Numeric Ranges to Extract

Follow the field name or a keyword with a colon (:) and a range of numerals to be extracted from the field value. You can specify a substring numeric range directly after the field name or after a keyword indicating the part of the phone number.

Primary Phone Field User Property in Business Components

Any business component can have a named user property called Primary Phone Field. The property value is the field name of the same business component that contains the phone number and that must be dialed when a make-call command is invoked on an applet that uses this business component.

For example, the Account business component can have a Primary Phone Field user property set to the value Main Phone Number. This tells Communications Server that Main Phone Number is the field that must be dialed by default when dialing is requested on an account.

Under certain circumstances, the value of the @Phone macro is equal to the field designated as the Primary Phone Field.

For more information about specifying user properties, see the developer documentation on the Siebel Bookshelf.

Related Books

Configuring Siebel Business Applications

Configuring Siebel Open UI

Using Siebel Tools

Siebel Developer's Reference

Work Item Attributes

The following table describes work item attributes that you can specify in values for parameters that support macro expansion. Communications events and commands can reference these attributes as subparameters of the parameter Param, or as elements within other parameter values where macro expansion is supported. The following macros, when used in parameter values, can process these attributes: @SelectedWorkItem, @DeselectedWorkItem, and $GetWorkItemAttr.

You can use the WorkTrackingObj parameter in event log or command data definitions to store or update custom work item attributes. You can use the AfterWork event log parameter to update database records that store work item attributes after work items are released. (You can also use the WorkObject event response parameter to update database records for tracking work items.)

For example, if an event log includes a parameter definition like the following, then ContactId becomes a custom work item attribute that is available for use wherever work item attributes can be accessed. For example, commands that update the customer dashboard can access such attribute values:

WorkTrackingObj.ContactId = "{Contact.Id}"

Alternatively, if an event log includes a parameter definition like the following, then text that you specify is displayed in the Work Items list in the communications toolbar:

WorkTrackingObj.Description="your descriptive text goes here"

Note: Of the predefined work item attributes described in the following table, only ParentWorkItemID and Description can be updated.

For more information about the WorkTrackingObj and AfterWork event log parameters, see Event Logs. For more information about the WorkTrackingObj command data parameter, see Command Data. For more information about the WorkObject event response parameter, see Event Responses. For additional attributes that you can specify in event handlers, see Driver Event Attributes.

Table Work Item Attributes

Attribute Name	Description
ChannelType	The language-independent value representing the channel type of this work item.
ChannelTypeLocale	The locale-dependent value for the channel type of this work item.
Description	A description of this work item. The value for this attribute comes primarily from the client handle methods WorkItemStarted and IndicateNewWorkItem. For more information, see Developing a Communications Driver
DriverWorkTrackID	The ID number of this work item as tracked by the driver.
IsRevoked	Indicates whether the work item has been rejected by an agent (using the Accept or Reject dialog box). Possible values are True or False (the default is False). This attribute is True whenever the service handle method RevokeQueuedWorkItem has been invoked for the work item.
ParentWorkItemID	The ID number of the parent of this work item. Note the following behavior for parent and child work items: When a parent work item is released, all child work items are released. When a parent work item is suspended, all child work items are suspended. When a parent work item is resumed, all child work items are resumed. When a child work item is started or resumed, the parent work item gains the focus. Agent can use the Work Items list in the communications toolbar to select a child work item and operate on this child work item individually. Parent and child work items can be of different channels, such as when an outbound voice call is placed to a customer who initiated an email work item. For more examples, see the sample communications configurations provided with Siebel Business Applications.
ProfileName	The communications driver profile for which this work item is applicable.
ViewBookmark	The bookmark for the view which was current when this work item was suspended. The bookmark data is serialized and compressed into a string.
WorkDuration	The duration of this work item. The value is the same as the @WorkDuration macro.
WorkItemID	The ID number of this work item.
WorkObjectID	The work tracking object ID number. The value is the same as the @WorkObjectID macro.
WorkStartTime	The start time of this work item. The value is the same as the @WorkStartTime macro. The value for this attribute comes primarily from the client handle method WorkItemStarted. For more information, see Developing a Communications Driver.
WorkState	The state of this work item. Possible values are Created, Active, Suspended, and Released. The value for this attribute comes primarily from client handle methods. When IndicateNewWorkItem is invoked, the WorkState value is Created. When WorkItemStarted is invoked, the WorkState value is Active. When WorkItemSuspended is invoked, the WorkState value is Suspended. When WorkItemResumed is invoked, the WorkState value is Active. When WorkItemReleased is invoked, the WorkState value is Released. For more information, see Developing a Communications Driver.

Macro-Expansion Examples

The examples in the following table demonstrate macro-expansion usage. From the nominal parameter value shown in the second column, macro expansion calculates the resulting value shown in the third column. Each example is explained to show how the result was generated.

Table Macro-Expansion Examples

Parameter Name	Parameter Value	Result	Explanation
Param.PhoneNumber	#8[Phone #: 7-10]	#85000	If the value of the Phone # field in the current business component is 6505065000, then macro expansion extracts the seventh through tenth digits of the phone number. The characters #8 prefix the result. Because no keyword is specified, the Number part is assumed, and the country code and extension are excluded. Because the macro-expansion characters representing the phone number are enclosed in brackets, this Phone # field can be in a dialog box or in the current business component.
Param.PhoneNumber	{Phone #: Number:6-10}	75000	Assume the same value for the Phone # field as in the previous example. Macro expansion extracts the sixth through tenth digits of the phone number. In this example, the Number keyword is explicitly specified. Because the macro-expansion characters representing the phone number are enclosed in braces, this Phone # field cannot be in a dialog box.
Param.GetId	{Id}	10-CSAE	If the Id field for a record in the current business component is 10-CSAE, then macro expansion yields this string as the result.
Param.Greet	\{Hi\}	{Hi}	The backslashes allow the braces to be included literally as part of the result. As a result, Hi is not interpreted as a field name.
Param.ExtField	{Extension}	5000	For a field called Extension, macro expansion extracts the value of this field, for example, 5000. Because the Extension field is not of type DTYPE_PHONE, you cannot use keywords to specify a phone number part to extract.
Param.Ext	{Work Phone #: Extension}	6000	If the value of the Work Phone # field of the current business component (for example, Contacts) is (650)5065000 x6000 for a U.S. phone number and extension, then only the extension number after the x is extracted.
Param.PhoneNumber	{Work Phone #: Lookup}	phone num	Macro expansion generates a phone number based on applying the dialing filters to the data in the Work Phone # field of the current business component.
Param.PhoneNumber	{@Phone: PhoneTypeLookup}	phone num	Macro expansion generates a phone number based on the logic described for the @Phone macro, in Macros for Parameter Values. Dialing filters are applied only if a field is of type DTYPE_PHONE.

Working with Dialing Filters

Dialing filters are used by the Siebel application to manipulate telephone numbers for voice calls made, transferred, or for conference calls made.

Dialing filters specify a set of phone-number translation rules that are invoked when the Lookup or PhoneTypeLookup keyword is specified in macro-expanded text in a communications command for the voice channel (using Siebel CTI). Dialing filters are defined as configuration parameters in the All Configurations view in the Administration - Communications screen.

In each of the examples in this topic, the first set of numbers is searched for. If there is a match, then the searched numbers are translated to the numbers after the -> symbols (hyphen and ninety degree angle bracket).

Filter rules are checked for matches in numerical sequence. The last rule in the sequence must always be defined to match any number.

The numeric elements in the names of the filter rule parameters are applied by string comparison, from small to large. For example, this means that a dialing filter named DialingFilter.Rule11 is applied before one named DialingFilter.Rule2. Consequently, use the same number of digits for each rule, according to your total anticipated number of rules. For example, the numeric elements in the filter rules might use a sequence starting with 000, followed by 001, and so on, up to 999.

Note: How dialing filters actually function is subject to the command data definition for the command that is performing the make-call operation.

By default, the Lookup and PhoneTypeLookup keywords used in command data definitions do the following:

• Treat a phone number as domestic (that is, omit the country code) if the country code matches the current locale.

• Treat a phone number as international (that is, include the country code) if the country code does not match the current locale.

For Siebel CTI implementations supporting multiple call centers, consider the dialing filter requirements among the factors in deciding how to organize your agents in communications configurations. You might decide, for example, to ensure that all agents included in a single configuration are located within a single location for which the same set of dialing filters applies. For example, this grouping might be defined as a particular call center facility, or a particular locale corresponding to a country code.

For more information about configuration parameters, including DialingFilter.RuleN, see Specifying Parameters for a Communications Configuration.

For more information about the Lookup and PhoneTypeLookup keywords, keywords to represent parts of phone numbers, phone-number formatting, and the $DialingRuleMethod macro, see Using Macro Expansion for Character Fields.

For more information about international telephone numbers, see Siebel Applications Administration Guide.

Dialing Filter Examples

The following table provides examples of dialing filter rules.

Table Dialing Filter Examples

Dialing Filter	Description
DialingFilter.Rule001 = "650506->"	This rule takes a ten-digit domestic phone number (for example) and translates it into four digits for dialing an internal extension. You can use such a rule for internal calls, call transfers, or call conferences, where, for example, the U.S. area code 650 and prefix 506 apply to the call center. Or use such a rule for calls, transfers, or conferences to another call center, where this area code and prefix apply to the destination call center. For more information, see Configuring Remote Transfers and Conferences.
DialingFilter.Rule002 = "650->9"	This rule takes a ten-digit domestic phone number (for example) and translates it into eight digits for dialing an outside local call in the U.S.
DialingFilter.Rule003 = "+33->901133"	This rule takes a French phone number (any number for which the country code is 33, when the current locale is not France) and prefaces it with the digits that are required for dialing an international number when your locale is the U.S. or Canada.
DialingFilter.Rule004 = "+->9011"	This rule takes any international phone number (that is, any number for which the country code does not match the current locale) and prefaces it with the digits required for dialing an international number when your locale is the U.S. or Canada.
DialingFilter.Rule005 = "->91"	This rule takes any domestic phone number (that is, any number that did not match the preceding rule) and prefaces it with the digits required for dialing an outside call to another area code in the U.S.

For the examples in the previous table, note the following:

• If a telephone number matches 650506****, then Rule001 is applied.

• If the number does not match this pattern, but matches 650*******, then Rule002 is applied.

• If the number does not match this pattern, but matches a French number (when the current locale is not France), then Rule003 is applied.

• If the number does not match this pattern, but matches any international number (for which the country code does not match the current locale), then Rule004 is applied.

• If the number does not match any of these patterns, then Rule005 is applied. As noted, the last defined rule must match any number.

The following example is an alternative definition for DialingFilter.Rule002.

DialingFilter.Rule002 = "650->$DialingRuleMethod(service.method)"

This rule takes a ten-digit domestic phone number (for example) and translates it into a number that is determined by the specified business service method. You can use such a rule to invoke a method that provides a correct phone number to dial, where other filter rules might not be able to filter unambiguously. For example, if internal numbers use a prefix, such as 506, that is also used outside the company, then the business service invoked using this macro can determine the correct number to dial by identifying the specific number as internal or external.

The following example is an alternative definition for DialingFilter.Rule004.

DialingFilter.Rule004 = "+->$DialingRuleMethod(service.method)"

This rule takes an international phone number and translates it into a number that is determined by the specified business service method.

Configuring Telesets for Hoteling

You can configure the telesets in your call center for hoteling, which allows an agent to log in to the Siebel application from any one of a pool of telesets and computers that have been configured for this purpose and allows the agent to use voice communications features.

You configure hoteling by associating a teleset with the host name of the computer that is located at the same station as the teleset. Do this in the All Telesets view in the Administration - Communications screen. For more information about configuring telesets, see Specifying Telesets.

If you have specified a host name to enable hoteling for a teleset, then any agent logging in to the Siebel client on the hoteling computer uses the standard extension of the hoteling teleset that is associated with that computer’s host name.

Hoteling Requirements and Issues

Note the following requirements and issues for implementing hoteling:

• After each agent is added to a communications configuration, the agent is typically associated with a teleset. However, associating a computer’s host name with a teleset overrides this association and allows that computer to be used by multiple agents for hoteling.

• If an agent logs in to the Siebel application on a computer that is not associated with a hoteling teleset, then voice communications are enabled for the agent only if that agent is explicitly associated with the teleset at the new location.

• You can configure hoteling only for computers that are always expected to be located at the same station as the hoteling teleset. For example, although you can configure hoteling for a laptop computer that an agent connects to the network at any of several locations, you can configure it only for a single location where a particular teleset is located.

• Agents who log in to a hoteling computer cannot specify any other teleset in the Communications options of the User Preferences screen. The agent can specify a different extension for this teleset, however, if more than one extension is defined.

• For internal calls to employees who use hoteling telesets, you can configure commands to retrieve the run-time extension of the employee by using the $HotelingPhone macro. For more information, see Macros for Parameter Values.

• As of Siebel Innovation Pack 2016, a separately installed client module, Desktop Integration Siebel Agent (DISA), is used to obtain the local computer’s host name for hoteling purposes. It is recommended to install Desktop Integration Siebel Agent on each agent computer that will be used for hoteling.

  If Desktop Integration Siebel Agent is not installed or is not running, then the host name is obtained from the HTTP request header.

  However, if Desktop Integration Siebel Agent is not installed or is not running and proxy connections are enabled in the browser, then, for agents to be able to use hoteling, you must set the parameter AutoLoadDriver to False for the communications configuration. This setting allows agents to manually enter the computer’s host name and to use hoteling. For more information about the AutoLoadDriver parameter, see Parameters for Communications Configurations.

  For more information about installing and deploying Desktop Integration Siebel Agent, see 2107511.1 (Article ID) on My Oracle Support. See also the Siebel Installation Guide for the operating system you are using.

Configuring Multitenancy

Siebel Communications Server supports the multiple-organization feature in the Siebel Business Applications. This feature, called multitenancy for call centers, helps provide the contact center, including those supporting multiple channels, with flexibility to organize its work and agent resources and to control visibility of data.

Contact centers that provide outsource services to other companies, or to multiple internal entities, can support these multiple entities using multitenancy.

In an outsource contact center, agents with expertise supporting products or services from Company A, for example, are assigned positions in the organization defined for Company A, while agents supporting Company B are assigned positions in the organization defined for Company B.

You can assign agents to multiple positions in multiple organizations, according to their expertise and the contact center’s operational requirements.

For more information about positions, responsibilities, and organization visibility for Siebel applications, see Siebel Security Guide and Siebel Applications Administration Guide.

This topic contains the following information:

• Setting the Multi Tenancy Configuration Parameter

• Organization Visibility and Positions

Setting the Multi Tenancy Configuration Parameter

The Siebel Communications Server configuration parameter MultiTenancy allows you to specify whether organization-visibility rules must apply:

• Set this parameter to True if your Siebel implementation uses multitenancy. The parameter is set to True by default.

• Set this parameter to False if your Siebel implementation does not use multitenancy.

For more information, see Specifying Parameters for a Communications Configuration.

Organization Visibility and Positions

Some Siebel data records are visible only to users whose current position is within a particular organization. Other records are visible to users whose positions are in different organizations. You can associate records with one or more organizations.

Each user can have only one position active at a time. In some situations, a user might be allowed to see data for all of that user’s assigned positions.

Organization visibility is defined for both business components and views.

Organization Visibility for Business Components

Organization visibility is defined for each business component, determining which of the following applies to the business component:

• Visibility is for one organization.

• Visibility is for multiple organizations.

• Organization visibility does not apply.

A business component for which organization visibility applies is said to be position-dependent.

Organization Visibility for Views

Organization visibility is enforced for each view. Multiple views that display data for the same business component might enforce visibility differently. For example, in the Contacts screen, the All Contacts view allows a user to view contact records within one organization, while the All Contacts across Organizations view (not available for all users) allows a user to view all contact records for all organizations.

You can determine whether a view enforces organization visibility by using Siebel Tools. For each view object definition:

• Organization visibility is enforced for the view if the field Visibility Applet Type is set to Organization and the field Admin Mode Flag is not checked (False).

• Organization visibility is not enforced for the view if the field Admin Mode Flag is checked (True).

Changing Position Manually or Automatically

For the agent to view some data, such as for certain screen pops, the agent’s position must be changed, either manually or automatically. At any time, an agent can manually change the current position in the Siebel application by using the Change Position view in the User Preferences screen.

If the agent is the recipient of a screen pop for an incoming or transferred work item or a conference call, then the agent’s position is changed automatically, as appropriate for the context and for the screen-pop data. When an agent retrieves a paused work item, the original screen pop and position are both restored. As described earlier, the business component determines the organization visibility for the screen-pop data, enabling the agent’s position to be changed, as necessary.

What screen-pop data to display is determined by the current business component, which is specified in the QueryBusComp parameter in the event response. For more information about event responses, see Event Responses.

After an agent’s position has been automatically changed, when a work item is concluded, the agent’s position remains what it was changed to. The agent must manually change the position again if the new current position is not appropriate.

Scenarios for Generating Screen Pops and Changing Position

When a position is changed, a message is displayed to the user. If the position is not changed, then no message appears, except in certain error conditions. Application behavior for generating screen pops and changing positions varies for each of the scenarios is described as follows:

• If the agent’s current position matches the screen-pop data, then the screen pop is displayed and the agent’s position is not changed.

• If the agent’s current position does not match the screen-pop data, and the agent has one other position that matches the data, then the screen pop is displayed and the agent’s position is changed.

• If the agent’s current position does not match the screen-pop data, and the agent has more than one position that matches the data, then the screen pop is displayed. The agent’s position is changed to the first position that matches the data, and the agent is allowed to view all data that is defined to be visible for all the agent’s assigned positions.

  The Siebel client allows the agent to view this data by using the VIEW_ALL mode, which ignores organization-visibility rules. A message advises the agent to manually change to a position appropriate for the screen-pop data, so that the agent can subsequently navigate to related records without hindrance.

• If the agent does not have a position that allows the agent visibility to the screen-pop data, then no screen pop is displayed.

• If the business component for a view does not have enough data to determine organization visibility, then the screen pop occurs without restriction. The position is not changed. No error message is displayed.

• Organization-visibility rules for screen pops apply to inbound work items and to transfers and conferences between contact-center users. For inbound work items, the Siebel application always attempts to set the user’s position automatically. For transfers and conferences, the position is set only if the screen-pop view enforces organization visibility.

• When a view has no records displayed, organization-visibility rules do not apply to screen pops for call transfers or conferences.

• When organization visibility is not enforced for a view, organization-visibility rules are not used when changing an agent’s position.

• Multitenancy affects screen pops differently for different views. Siebel application developers, contact-center managers, and end users must understand how this issue relates to screen pops.

  Some views, such as administration views, do not have organization-visibility rules. Some views, such as views whose names include the phrase Across Organizations, allow users to view records for multiple organizations. Organization-visibility rules are applied to screen pops according to the business component data. Verify organization-visibility behavior, changing position manually as needed, for the views involved in your screen pops.

Configuring Communications Login and Logout

Agents can log in to, or log out of, call-center communications systems that work with Siebel Communications Server, either automatically or manually. For more information about login and logout issues, see the following:

• For end user login procedures, see Using the Communications Toolbar.

• For a description of logging in to selected ACD queues and of the end user preference Auto Login to Call Center at Startup (in the Communications options in User Preferences), see Setting Communications User Preferences.

• For descriptions of the configuration parameters AutoLogin, AutoLoginCmd, AutoLogout, AutoLogoutCmd, PreferenceLoginCmd, and PreferenceLogoutCmd, see Parameters for Communications Configurations.

This topic contains the following information:

• Automatic and Manual Login and Logout

• Login and Logout Command Configuration

Automatic and Manual Login and Logout

This topic provides a brief overview of the automatic and manual login and logout capabilities provided for communications-enabled Siebel applications.

Automatic Login

With automatic login, after starting the Siebel application, the end user is automatically logged into all applicable communications systems. Administrators can enable or disable automatic login for all users, or allow each user to specify whether to log in automatically.

When automatic login is in effect, using the Connect command in the File application-level menu in order to log in to a different Siebel database, or in order to log in as a different Siebel user, logs you out of the communications systems and then automatically logs you in again.

Agents who use ACD queues can manually log in to of any of the queues with which they are associated. Agents do this in the Communications options of the User Preferences screen.

Manual Login

With manual login, after starting the Siebel application, the end user clicks the Log In button on the communications toolbar in order to log in to the applicable communications systems. Automatic login must be disabled for all users or for the individual user.

When manual login is in effect, using the Connect command in the File application-level menu in order to log in to a different Siebel database, or in order to log in as a different Siebel user, logs you out of all applicable communications systems and you must log in again manually.

Agents who use ACD queues can manually log in to any of the queues with which they are associated. Agents do this in the Communications options of the User Preferences screen.

Automatic Logout

With automatic logout, when the end user exits the Siebel application, the end user is automatically logged out of all applicable communications systems. Administrators can enable or disable automatic logout for all users.

Agents who use ACD queues can manually log out of any of the queues with which they are associated. Agents do this in the Communications options of the User Preferences screen.

Manual Logout

With manual logout, the end user can click the Log Out button on the communications toolbar in order to log out of the applicable communications systems. Automatic logout must be disabled for all users.

Agents who use ACD queues can manually log out of any of the queues with which they are associated. Agents do this in the Communications options of the User Preferences screen.

Login and Logout Command Configuration

This topic documents example command and command data definitions that determine the availability of login and logout functions for the communications toolbar and for menus. For more information:

• About all command and command data parameters shown in this topic, see Configuring Events and Commands.

• About configuring the communications toolbar and communications menu items, see Configuring User Interface Elements.

• About macros such as @PrimaryQueueList, see Macros for Parameter Values.

Login Commands

In the following login commands, SignOnGroup and SignOnGroupInMenu both specify the same set of subcommands, which control login functionality in the communications toolbar and in the Communications submenu of the Tools application-level menu, respectively.

[Command:SignOnGroup]
    Hidden         = "True"
    Description    = "Log in"
    ExecuteAll     = "True"
    SubCommand_1   = "LoginToPBX"

[Command:SignOnGroupInMenu]
    MenuPosition   = "20"
    Title          = "Log In"
    Description    = "Log in"
    SubCommand_1   = "LoginToPBX"

[Command:LoginToPBX]
    MenuPosition    = "20.1"
    Title           = "Log In (Phone)"
    DeviceCommand   = "LogIn"
    CmdData         = "LoginToPBX"

    [CmdData:LoginToPBX]
    Param.ACDQueue  = "{@PrimaryQueueList}"
    Param.AgentId   = "{@AgentId}"
    Param.AgentPin  = "{@AgentPin}"

Logout Commands

In the following logout commands, SignOffGroup and SignOffGroupInMenu both specify the same set of subcommands, which control logout functionality in the communications toolbar and in the Communications submenu of the Tools application-level menu, respectively.

[Command:SignOffGroup]
    Hidden         = "True"
    Description    = "Log out"
    ExecuteAll     = "True"
    SubCommand_1   = "LogoutFromPBX"

[Command:SignOffGroupInMenu]
    MenuPosition   = "22"
    Title          = "Log Out"
    Description    = "Log Out"
    SubCommand_1   = "LogoutFromPBX"

[Command:LogoutFromPBX]
    MenuPosition    = "22.1"
    Title           = "Log Out (Phone)"
    DeviceCommand   = "LogOut"
    CmdData         = "LogoutFromPBX"

    [CmdData:LogoutFromPBX]
    Param.ACDQueue  = "{@PrimaryQueueList}"

Configuring Remote Transfers and Conferences

You can configure Siebel Communications Server to allow agents to initiate, transfer, and conference voice calls between call centers, with attached data to support screen pops. This capability might be supported for your CTI middleware.

This topic contains the following information:

• Creating Communications Configurations

• Specifying Dialing Filters

• Using Macros to Identify Remote Call Centers

Creating Communications Configurations

You must create separate communications configurations for each call center. For example, for call centers in San Mateo and Oakland, create a configuration called San Mateo and a configuration called Oakland.

Each configuration must define the agents applicable to that physical call center. All configurations must exist in the Siebel database at all call centers. In the example, both the San Mateo and Oakland configurations exist at both call centers.

Note: Session-based communications functionality, such as Siebel CTI, is supported only for single-database environments. Session communications capability is not supported for users of a regional database, to which data is replicated using Siebel Replication Manager.

Specifying Dialing Filters

Each communications configuration must contain configuration parameters specifying dialing filters, in order to support dialing for both locations. These parameters can have names such as DialingFilter.Rule1, DialingFilter.Rule2, and so on. For more information, see Specifying Parameters for a Communications Configuration.

For example, assume that you are configuring communications between two call centers located in the U.S. The San Mateo call center is located in area code 650 and has exclusive use of the prefix 506. The Oakland call center is located in area code 510 and has exclusive use of the prefix 788. Five-digit dialing is supported between these call centers.

With dialing filters such as the examples shown in the following table, phone numbers for call transfers and call conferences initiated from Siebel Communications Server from either site to the other site (or internal to one site) are converted from ten-digit numbers, as they are stored in the Siebel database, to four-digit numbers, then prepended with a numeral such as 1 or 2 for five-digit dialing.

Table Dialing Filter Parameter Examples

Parameter Name	Parameter Value
DialingFilter.Rule1	510788->1
DialingFilter.Rule2	650506->2

In these examples, the resulting five-digit numbers match extensions defined (with the same number of digits) in the organization’s switches and match the extensions defined in the Administration - Communications screen.

The macro $DialingRuleMethod can help you to implement advanced logic for your dialing filters. For more information, see Macros for Parameter Values.

Using Macros to Identify Remote Call Centers

This topic describes how you can use parameters to obtain a call center configuration name.

In the communications configurations for San Mateo and Oakland, you add a command parameter like one of the examples in this topic to the command data definition for any applicable commands, such as commands used for initiating a call transfer or conference call to another call center.

The command data parameter Param.RemoteConnectStr can include one of two related macros in its parameter value in order to obtain the configuration name:

• $RemoteConnectStr. This macro derives the name of a remote call center’s communications configuration, using the agent’s extension number as a parameter. The following table shows examples:

  Table $Remote Connect Str Examples

  Parameter Name	Parameter Value
  Param.RemoteConnectStr	[$RemoteConnectStr(@Phone)]
  Param.RemoteConnectStr	{$RemoteConnectStr(Owner Phone:Lookup)}

  For more information, see Macros for Parameter Values.

• $RemoteConnectStr2. This macro derives the name of a remote call center’s communications configuration, using the agent’s employee ID as a parameter.

  For example, where the Employee business object and business component are specified, the parameter definition uses the business component field Id to get the name of the configuration. The following table shows an example:

  Table $RemoteConnectStr2 Example

  Parameter Name	Parameter Value
  Param.RemoteConnectStr	[$RemoteConnectStr2(Id)]

Example Command Using $RemoteConnectStr

The example command and command data definitions shown in the following table and the second table in this topic, using the $RemoteConnectStr macro, use the Owner Phone field in the Service Request business component to determine which call center has the phone number. In this example, the Param.RemoteConnectStr command parameter gets the extension number for the call recipient by macro-expanding Owner Phone:Lookup. The Siebel application looks up which configuration has this extension and returns the name of the call center with this extension.

Table Command: BlindTransferToSROwner

Parameter Name	Parameter Value
Description	Blind Transfer to Service Request Owner
DeviceCommand	TransferMute
Hidden	True

The following table shows a command data definition for this command definition.

Table Command Data: BlindTransferToSROwner

Parameter Name	Parameter Value
BusComp	Service Request
RequiredField.'Owner Phone'	?*
Param.PhoneNumber	{Owner Phone:Lookup}
AttachContext	True
Param.CallNotifyText	Blind transfer from {@UserName} about SR {Id}...
Param.RemoteConnectStr	{$RemoteConnectStr(Owner Phone:Lookup)} (In this example, Owner Phone is a field from the Service Request business component.)

Using the Push Keep Alive Driver for Session Connections

The Push Keep Alive communications driver provides a heartbeat message that is useful in maintaining connections for your communications sessions in some environments. You use this driver with Communications Session Manager, such as when you are using Siebel CTI.

The Push Keep Alive driver helps to solve problems that might be experienced in some environments, where push communications sessions between the Application Object Manager and a user’s Web browser are sometimes dropped. A connection might be dropped if messages have not been pushed to an agent for a particular length of time.

The Push Keep Alive driver sends a heartbeat message to the Application Object Manager and to each agent user’s browser, at a regular interval. This heartbeat message allows the push connection applicable to each agent’s communications toolbar not to be dropped in such cases. The heartbeat interval is specified using a driver parameter.

Note: When you use the Push Keep Alive driver, you must also set the ChannelCleanupTimer configuration parameter to make sure that abandoned connections for communications sessions are dropped promptly. For more information about the ChannelCleanupTimer configuration parameter, see Parameters for Communications Configurations. For information about how to set this parameter, see Specifying Parameters for a Communications Configuration.

Configuring the Push Keep Alive Driver

The following procedure describes how to configure the Push Keep Alive driver. Descriptions of the driver settings and the default driver parameter values follow.

To use the Push Keep Alive driver

1. Start the Siebel application, such as Siebel Call Center, logging in as the system administrator (for example, as the user SADMIN).

2. Navigate to the Administration - Communications screen, then the Communications Drivers and Profiles view.

3. Click the Profiles tab and enter a new record with a name that identifies the profile with the Push Keep Alive communications driver. For example, enter Push Keep Alive.

4. In the Profile Parameter Overrides child applet, create records with values similar to those listed in the following table.

   Parameter	Value
   Name	Select PushKeepAliveTimer from the drop-down list.
   Value	Enter the time interval (in seconds) between the Push Keep Alive driver sending messages. For example, enter 180 to have the driver send a heartbeat message every 180 seconds.

5. Click All Configurations in the application link bar and select your configuration in the displayed list.

6. Click the Profiles screen tab.

   The list of profiles currently associated with your configuration appears.

7. Click New.

   The Add Communications Profiles dialog box appears. This dialog box displays the list of currently available profiles.

8. Select Push Keep Alive, then click OK.

   This associates the Push Keep Alive communications driver with your configuration. It means that a heartbeat message is sent at the interval that you specify (for example, every 180 seconds).

9. Do one of the following:

   • If you use the Communications Configuration Manager server component to cache your configuration, then shut down and restart your Siebel Server to apply the changes made in steps Step 1 to Step 8.

   • If you do not use the Communications Configuration Manager server component, then log out and log into the application for these changes to take effect.

     For more information about the Communications Configuration Manager component, see Administering Communications Configuration Manager.

Push Keep Alive Driver Settings

The following table lists the settings for the driver record for the Push Keep Alive driver. These settings appear in the Communications Drivers and Profiles view in the Administration - Communications screen.

Caution: The values shown in the following table are presented for reference only. Do not modify the predefined values for this driver.

Table Push Keep Alive Driver Settings

Field Name	Value
Name	Push Keep Alive
Channel Type	Push Keep Alive
Inbound	Off
Outbound	Off
Interactive	On
Channel String	Push Keep Alive
Library Name	sscmimed

Push Keep Alive Driver Parameters

The following table lists the supported parameters for the Push Keep Alive communications driver.

Table Push Keep Alive Driver Parameters

Name	Required	Default Value	Description
LogDebug	No	False	True or False If True, then data output to the log file is more detailed.
LogFile	No	push_{@UserName}.log	The name of the file where logging information is written. If this parameter is empty, then no log file is generated. Logging data is always appended to this file. Log files are created in the log subdirectory of the Siebel Server installation directory. Optionally, if you want to use a single log file in a multichannel environment, then you can specify the same log file name for all of the interactive drivers that you are using.
MaxLogKB	No	128	Specifies the maximum size of the log file, in kilobytes (KB). When the log file is full, it is emptied completely, then logging begins again.
PushKeep AliveTimer	Yes	0	Specifies the interval, in seconds, for the heartbeat message sent by the Keep Push Alive driver to the Application Object Manager and to each agent’s Web browser. For example, if this parameter is set to 180, then the heartbeat message is sent every 180 seconds. The default value, 0, specifies that no heartbeat message is sent. Typically, this parameter is defined as a parameter override in a driver profile that has been associated with the communications configuration.
ReleaseLogHandle	No	True	Indicates that the log file handle for each agent is released periodically, after logs have been generated. The default setting of True provides better performance. When ReleaseLogHandle is False, however, some log files might not be generated if the number of concurrent users exceeds the file-handle capacity provided by the operating system.

Using Business Services with Siebel Communications Server

This topic describes some ways in which you can use Siebel business services with Siebel Communications Server.

Business services represent encapsulated functionality in the form of methods that Siebel application modules or scripts can call within the Siebel application environment. Many types of Siebel Business Applications functionality, including Communications Server functionality, can be accessed as methods of standard business services. Siebel applications running on all client types support Siebel business services.

This topic describes using business services in two general ways:

• Accessing Siebel Communications Server functionality outside of the standard means offered by the Siebel application user interface. For example, Siebel Workflow invokes Communications Server business services, and Siebel VB and Siebel eScript scripts can invoke Communications Server business services.

• Integrating Siebel Communications Server events and commands with Siebel business services, in particular with custom business services or business services other than those provided for Communications Server.

Siebel Communications Server supports multiple business services that support the different functional areas of interactive session communications, outbound communications, and inbound communications.

This topic contains the following information:

• Invoking Siebel Communications Server Business Service Methods

• About Using Business Services with Events and Commands

• Invoking a Command Through the Business Service Model

• Invoking a Business Service Method from a Command

• Invoking a Business Service Method from an Event Handler

• Invoking a Business Service Method from an Event Response

Related Books

Siebel Email Administration Guide

Siebel Business Process Framework: Workflow Guide

Configuring Siebel Business Applications

Configuring Siebel Open UI

Using Siebel Tools

Siebel Developer's Reference

Siebel Applications Administration Guide (and other books for Siebel EAI)

Invoking Siebel Communications Server Business Service Methods

Siebel Communications Server includes two business services that support session communications for agents:

• Communications Client. Supports the communications user interface features such as the communications toolbar and communications menu commands. This business service aggregates the Communications Session Manager business service. It is not involved with server-based communications functionality.

• Communications Session Manager. Provides an interface to session-based communications functionality at the server level. Through Server Request Broker and Server Request Processor, this business service communicates with the Communications Session Manager server component. This business service does not deal with the communications user interface.

• Note: Because the Communications Session Manager business service is aggregated by the Communications Client business service, you can access all Communications Session Manager business service methods from the Communications Client business service. For configuring communications events or commands, the communications toolbar, or the Application Object Manager, you must invoke all methods through the Communications Client business service.

These business services work together and can run on the Application Object Manager supporting instances of the Siebel Web Client. They run together with the channel manager, depending on how you have deployed interactive session communications. For more information, see Enabling Session Communications.

You can invoke methods of Communications Server business services from outside Communications Server. You can invoke a method from an applet, a script, a workflow, or another business service, or invoke it in some other way. Siebel Workflow and scripts for Siebel VB or Siebel eScript can invoke Communications Server business services. For more information about Communications Server business services, methods, and arguments, see Siebel Communications Server Business Services.

About Using Business Services with Events and Commands

This topic describes scenarios for integrating business services with communications event and commands. These scenarios are applicable to a contact center using Siebel CTI and related modules. These scenarios are as follows:

• Invoking a business service method from an event handler

• Invoking a business service method from an event response

  A business service method can also be invoked from an event log, but this scenario is not described here.

• Invoking a communications command from a business service method

• Invoking a business service method from a communications command

Invoking a Command Through the Business Service Model

You can set up a custom business service that invokes a command from a communications configuration. To set this up, you do the following:

• Create a communications command (and a corresponding command data definition) that is intended to be invoked from outside of Siebel Communications Server, and

• Modify or create an applet, script, or business service to invoke a particular communications command

The following examples are for a make-call command and a business service method that invokes this command.

The following table and the second table in this topic show an example of a command that is called by a custom business service. This example executes a MakeCall device command.

Table Command: Make CallFromCustomService

Parameter Name	Parameter Value
Description	Make Call from Custom Service
DeviceCommand	MakeCall
Hidden	True

The following table shows a command data definition for this command definition.

Table Command Data: MakeCallFromCustomService

Parameter Name	Parameter Value
Param.PhoneNumber	{Call Recipient Phone Number}
Param.DisplayText	{My Display Text}

The values for Call Recipient Phone Number and My Display Text are passed from the custom business service to the command when the command is invoked.

A business service must be implemented that invokes the command MakeCallFromCustomService. Communications Server retrieves the values of Call Recipient Phone Number and My Display Text from the input arguments of the business service method and assigns these values to the command data parameters Param.PhoneNumber and Param.DisplayText. The device command MakeCall is executed, using the values for these parameters.

Note: By default, communications commands are invoked from business service methods associated with communications toolbar buttons. For more information, see About Communications Panel and Communications Toolbar Configuration.

Invoking a Business Service Method from a Command

You can create or modify a command and a corresponding command data definition in the communications configuration to specify a Siebel business service and method to be invoked. To do this, you do the following:

• Use the command parameter ServiceMethod in a command to specify the name of the business service and method to invoke.

• Use the command parameter ServiceParam in the associated command data definition to specify argument names and values to pass to the business service method.

For more information about using these command parameters, see Commands and Command Data.

In the example shown in the following table and the second table in this topic, Communications Server invokes the method MyMakeCall of the business service MyMakeCallService and passes arguments to the service method. The value of the ServiceParam.PhoneNumber parameter is from the @Phone macro; the value of the ServiceParam.AgentID parameter is from the @AgentId macro.

At run time, commands that invoke business service methods are determined to be enabled or disabled by invoking from the applicable business service the method CanInvokeMethod("method_name"), where method_name is your business service method to be invoked. If True is returned, then you can invoke the method. If False is returned, then you cannot invoke the method and the command is disabled. No DeviceCommand parameter is included in this example, because the communications command is not designed to call a function on the external communications system.

Table Command: Make Call InService

Parameter Name	Parameter Value
Description	Make Call In My Service
ServiceMethod	MyMakeCallService.MyMakeCall
Hidden	True

The following table shows a command data definition for this command definition.

Table Command Data: MakeCallInService

Parameter Name	Parameter Value
ServiceParam.PhoneNumber	{@Phone}
ServiceParam.AgentID	{@AgentId}

Communications Server can invoke the methods of any business service, not only those, like this example, that pertain to communications.

Note: By default, several communications commands invoke business service methods. For examples, see the communications configuration data provided with Siebel Business Applications.

Invoking a Business Service Method from an Event Handler

You can create or modify an event handler in the communications configuration to specify a Siebel business service and method to be invoked. The business service method returns data to determine whether this event handler matches. In addition, it can perform other functions that the customer might want.

To configure this, you use the event parameters ServiceMethod and ServiceParam to specify the name of the business service and method to invoke and to specify argument names and values to pass to the business service method. For more information about using these event parameters, see Event Handlers.

In the example shown in the following table, Communications Server invokes the method MyMethod of the business service MyService and passes arguments attribute1 and attribute2 to the method, using the values of the ServiceParam.Param1 and ServiceParam.Param2 parameters.

Table Event Handler: On InboundCallReceived

Parameter Name	Parameter Value
ServiceMethod	MyService.MyMethod
ServiceParam.Param1	{attribute1}
ServiceParam.Param2	{attribute1}

The example event handler has the Device Event field set to the appropriate device event for the driver, such as an InboundCall event.

You can use the ServiceMethod and ServiceParam parameters to supplement or replace filter mechanisms using the Filter or FilterSpec parameters. You can also use this method to execute custom code before executing a specified event response. The business method must set a parameter of Result to a value 1 or 0 (or True or False):

• 1 (True) indicates that this event handler matches and is executed, and the associated event response is executed.

• 0 (False) invalidates this event handler; the next event handler is then evaluated.

Invoking a Business Service Method from an Event Response

You can create or modify an event response in the communications configuration to specify a Siebel business service and method to be invoked whenever this event response is invoked by an event handler.

To configure this, you use the event parameters ServiceMethod and ServiceParam to specify the name of the business service and method to invoke and to specify argument names and values to pass to the business service method. For more information about using these event parameters, see Event Responses.

The business service method might also alter the event data fields that were associated with the work item, such as to add new fields.

In the example event response shown in the previous table, the method MyMethod of the business service MyService is invoked to handle the event. The value of the ServiceParam.CallingDN parameter is from the ANI event data field; the value of the ServiceParam.Connection parameter is from the refId event data field.

Table Event Response: On InboundCallReceived

Parameter Name	Parameter Value
ServiceMethod	MyService.MyMethod
ServiceParam.CallingDN	{ANI}
ServiceParam.Connection	{refId}

When a business service method is invoked from an event response, the value for the output argument Continue is either True (1) or False (0). If Continue is True, then event handling as specified in the event handler that calls this event response proceeds (such as to generate a screen pop).

Integrating with Siebel Scripting Languages

You can use Siebel VB and Siebel eScript scripts in many ways to extend your communications-enabled Siebel applications. You can use Siebel VB and Siebel eScript scripts in the following ways:

• Communications events or commands can invoke Siebel VB or Siebel eScript scripts:

  • Communications events can invoke Siebel VB or Siebel eScript scripts, for instance on the arrival of an incoming work item or upon releasing a work item.

  • Communications commands can invoke Siebel VB or Siebel eScript scripts.

• Siebel VB or Siebel eScript scripts can invoke communications commands (using business service methods) and access event data fields or work item attributes:

  • Siebel VB or Siebel eScript scripts can invoke communications commands. Siebel VB-based menu items, buttons, or toolbar buttons can invoke commands that perform actions such as transferring a work item.

  • Siebel VB or Siebel eScript scripts can access data attached to a work item, such as event data fields like ANI, DNIS, digits collected from an IVR system, or Siebel work item attributes.

  • Siebel VB or Siebel eScript scripts can access methods and arguments of Communications Server business services. For more information, see Using Business Services with Siebel Communications Server and Siebel Communications Server Business Services

  • Siebel VB or Siebel eScript scripts can access run-time data provided by the macros described in Macros for Parameter Values.

  Siebel Communications Server integration with Siebel VB and Siebel eScript allows customers to write event handler functions and advanced communications commands in Siebel VB or Siebel eScript.

  The methods of all Communications Server business server methods are exposed and can be called with any applicable arguments. All event data fields (such as ANI, DNIS, and so on) are accessible. A Siebel VB or Siebel eScript script can be invoked on any communications event.

  A major use of scripting is to allow communications event handling (such as screen-pop logic). But you can also use it to take complete control of the communications technology: to obtain information about the current work item, to intercept events and perform the necessary handling, or to control communications work items (initiate work items, transfer work items, and so on).

  Note: You can define scripts in the general section of the application object or in a custom business service. Compile them into the Siebel runtime repository for the Siebel Application Object Manager.

This topic contains the following information:

• Integrating Scripting Using Server and Browser Scripts

• Integrating Scripting Using Server Scripts

Related Books

Siebel Object Interfaces Reference

Siebel eScript Language Reference

Siebel VB Language Reference

Configuring Siebel Business Applications

Configuring Siebel Open UI

Siebel Developer's Reference

Using Siebel Tools

Siebel Installation Guide for the operating system you are using

Siebel System Administration Guide

Integrating Scripting Using Server and Browser Scripts

Siebel eScript scripts are generally supported only for the Object Manager layer, not for the browser layer. For Siebel Web Client, the Object Manager is on the Siebel Server (Application Object Manager, such as SCCObjMgr_enu for Siebel Call Center in an ENU environment).

However, Siebel eScript scripts defined on the browser layer can use both server scripts and the @InvokeSWECommand special command. See the example in this topic for creating a communications command, a command for the Siebel Web Engine (SWE), and related server and browser scripts.

Note: Transferring data from a server script to a browser script is not supported, due to limitations of SWE commands.

For more information about the @InvokeSWECommand special command, see Special Commands for Device Commands.

Command Example

The following table and the second table in this section show an example command and associated command data definition that invokes the AlertTest SWE command.

Table Command: Alert

Parameter Name	Parameter Value
DeviceCommand	@InvokeSWECommand
CmdData	Alert

The following table shows a command data definition for this command definition.

Table Command Data: Alert

Parameter Name	Parameter Value
Param.SWECommand	AlertTest

SWE Command Example

In Siebel Tools, create a command named AlertTest with the properties shown in the following table. This SWE command is executed by the communications command shown earlier and in turn invokes the CTI_Test.Alert business service method.

Table SWE Command Example

Property Name	Value
Name	AlertTest
Business Service	CTI_Test
Force Enable	Y
Method	Alert
Target	Browser

Server and Browser Script Examples

Define the following server script in the CTI_Test business service. The PreCanInvokeMethod server script in the CTI_Test business service allows the SWE command to be enabled that in turn invokes the browser-layer scripting business service method Alert:

function Service_PreCanInvokeMethod (MethodName, &CanInvoke)
{
   var ReturnVal = ContinueOperation;
   if (MethodName == "Alert")
   {
      CanInvoke = "True";
      ReturnVal = CancelOperation;
   }
   return ReturnVal;
}

Define the following browser scripts in the CTI_Test business service. The PreInvokeMethod browser script invokes the Alert method to create an alert box in the browser.

function Service_PreCanInvokeMethod (methodName)
{
   if (methodName == "Alert")
      return true;
   else
      return ("ContinueOperation");
}

function Service_PreInvokeMethod (methodName, inputPropSet, outputPropSet)
{
   if (methodName == "Alert")
   {
      alert("CTI browser script test");
      return ("CancelOperation");
   }
   else
      return ("ContinueOperation");
}

In the previous steps, you have successfully created a new communications command named Alert. You can execute this command, for example, from the Communications submenu of the Tools menu, or from a keyboard shortcut. Another option is to further integrate this command with a server script, as illustrated in the following server script example:

function BrowserScriptTest()
{
   // Invoking Browser Script
   var ctibs = TheApplication().GetService("Communications Client"); 
   var ip = TheApplication().NewPropertySet();
   var op = TheApplication().NewPropertySet();
   ctibs.InvokeMethod("Alert", ip, op);
}

Integrating Scripting Using Server Scripts

Here are some examples of using business services and Siebel scripting with your communications configurations. These examples are for server-side scripting using Siebel eScript.

Event Response Example

The following table shows an example event response that invokes the server-layer scripting business service method CTI_Test.EvtBSGotoView. This event response retrieves work item data and generates a screen pop to the view Contact List View, with all contacts whose last name starts with the letter S.

Table Event Response: On Inbound CallReceived

Parameter Name	Parameter Value
ServiceMethod	CTI_Test.EvtBSGotoView
ServiceParam.myWorkItemID	{SiebelWorkItemID}
ServiceParam.ANI	{ANI}

Command Example

The following table and the second table in this topic show an example communications command and associated command data that invokes the server-layer scripting business service method CTI_Test.CmdBSGotoView. This command makes an outbound phone call to the number the user specified in the communications toolbar’s text input field.

Table Command: Make Call ToPhone

Parameter Name	Parameter Value
ServiceMethod	CTI_Test.CmdBSGotoView
CmdData	MakeCallToPhone
OnEditControl	True

The following table shows a command data definition for this command definition.

Table Command Data: MakeCallToPhone

Parameter Name	Parameter Value
ServiceParam.PhoneNumber	{@Phone:PhoneTypeLookup}
RequiredField.@Phone	?*
Param.CallNotifyText	Call from {@UserName}...

Server Script Examples

Define the following server scripts in the CTI_Test business service. These scripts are invoked by the event response and command described in Event Response Example and Command Example:

function Service_PreCanInvokeMethod (MethodName, &CanInvoke)
{
   var ReturnVal = ContinueOperation;
   switch (MethodName)
   {
      case "EvtBSGotoView":
      case "CmdBSGotoView":
      CanInvoke = "True";
      ReturnVal = CancelOperation;
   }
   return (ReturnVal);
}

function Service_PreInvokeMethod (MethodName, Inputs, Outputs)
{
   var ReturnVal = ContinueOperation;
   switch (MethodName)
   {
      case "EvtBSGotoView":
         EvtBSGotoView(Inputs, Outputs);
         ReturnVal = CancelOperation;
         break;

      case "CmdBSGotoView":
          CmdBSGotoView(Inputs, Outputs);
          ReturnVal = CancelOperation;
          break;
   }
   return (ReturnVal);
}

function EvtBSGotoView(Inputs, Outputs)
{
   // Getting input arguments from Event Response parameters
   var itemID = Inputs.GetProperty("myWorkItemID");
   var ANI = Inputs.GetProperty("ANI");
   // Invoking Business Service "Communications Session Manager" method
   var ctibs = TheApplication().GetService("Communications Session Manager");
   var ip = TheApplication().NewPropertySet();
   var op = TheApplication().NewPropertySet();
   ip.SetProperty("WorkItemID", itemID);
   ctibs.InvokeMethod("GetWorkItemInfo", ip, op);

   // Generate a screen pop to "Contact List View" with
   // all the contacts whose last name start with letter "S"
   var boGlobal = TheApplication().GetBusObject("Contact");
   var bcContact = boGlobal.GetBusComp("Contact");
   bcContact.SetViewMode(AllView);
   bcContact.ClearToQuery();
   bcContact.SetSearchSpec("Last Name", "S*");
   bcContact.ExecuteQuery(ForwardBackward);
   TheApplication().GotoView("Contact List View", boGlobal);
}

function CmdBSGotoView(Inputs, Outputs)
{
   // Getting input arguments from Command Data parameters
   var number = Inputs.GetProperty("PhoneNumber");
   // Invoking Business Service "Communications Client" method
   var ctibs = TheApplication().GetService("Communications Client"); 
   var ip = TheApplication().NewPropertySet();
   var op = TheApplication().NewPropertySet();
   ip.SetProperty("PhoneNumber", number);
   ip.SetProperty("ProfileName", "Siebel CTI");
   ctibs.InvokeMethod("MakeCall", ip, op);
}

Integrating with Siebel SmartScript

You can integrate Siebel Communications Server with Siebel SmartScript. For more information about SmartScript, see Siebel SmartScript Administration Guide.

This topic contains the following information:

• Invoking Siebel SmartScript Through Siebel CTI

• Displaying Communications Parameter Data in Siebel SmartScript

Invoking Siebel SmartScript Through Siebel CTI

Siebel Communications Server can invoke Siebel SmartScript in order to execute SmartScripts. To enable this behavior, you define parameters for the appropriate event response, using the views in the Administration - Communications screen. If the event response is executed in response to a corresponding event handler matching the call data parameters, then the script is invoked.

The following parameter and value must be added to the event response in order to enable the link between Communications Server and Siebel SmartScript:

• Parameter name: SmartScript.ScriptName

• Parameter value: Your_script_name

Any parameters received that are prefixed with SmartScript are passed to the SmartScript that is invoked. The available parameters are:

• SmartScript.ScriptName

• SmartScript.ScriptId

• SmartScript.LanguageCode

• SmartScript.CampaignId

• SmartScript.CampContactId

• SmartScript.ContactId

Either ScriptName or ScriptId must be specified in order to start a specific SmartScript. Otherwise, the agent is prompted, through the Choose Script dialog box, for the name of the script to run. In addition, either Siebel VB or Siebel eScript must be invoked to set the correct focus for the applicable business component.

For more information about defining event response parameters, see Event Responses.

Example Events to Invoke Siebel SmartScript Script

The following table shows an example event response that invokes a Siebel SmartScript script. The event handler that invokes this event response has the Device Event field set to the appropriate device event for the driver.

Table Event Response: On InboundCallReceived

Parameter Name	Parameter Value
SmartScript.ScriptName	Customer Service

Displaying Communications Parameter Data in Siebel SmartScript

If a SmartScript is invoked from Communications Server, then call data parameters are also available to be passed to SmartScript. You can access these parameters, which have the same names in SmartScript as in the communications configuration data, through either Siebel VB or Siebel eScript by using the GetParameter function against the SmartScript object. You can include parameters among the variables displayed in the customer dashboard by using the prefix CTI. For example, a variable using the GetParameter function might be defined as follows:

var s = GetParameter("CTI.ANI")

For more information about variables and programming for SmartScript, see Siebel SmartScript Administration Guide.

Integrating with the Customer Dashboard

The customer dashboard contains fields with customer-related data for an agent to view. Although the customer dashboard typically displays contact information, you can configure it in Siebel Tools to display other fields. The customer dashboard appears by default in the middle of a panel on the side of the Siebel application display area.

For more information about configuring the customer dashboard using Siebel Tools, see Configuring Siebel Business Applications.

You can configure customer dashboard fields to be populated, or cleared, automatically upon the execution of a communications event or command. For example, the fields might be populated from an event log when an inbound work item arrives, or cleared from an event log if the caller is not found in the database.

The fields in the dashboard are populated with customer data when you invoke a business service and method and pass values from business component fields or event data fields, such as the ANI phone number of a caller. If a match is produced, then the dashboard fields can be populated.

Related Topic

About the Communications Panel and Communications Toolbar Display

Related Books

Configuring Siebel Open UI

Configuring Siebel Business Applications

Example Events for Updating and Clearing Customer Dashboard

For example, the following sequence of event handler, event response, and event logs causes the dashboard to be populated with data, or cleared. In these examples, when a single matching contact record is found, the dashboard is populated. When no contact records are found, or multiple records are found, the dashboard is cleared. Adjust your event definitions as necessary, such as if you are using a different business component than Contact.

[EventHandler:InboundCallReceived]
    Filter.ANI = "*"
    Profile = ""
    Comments = ""
    Order = "1"
    Response = "OnInboundCallReceived"
    DeviceEvent = "TpAnswered"

[EventResponse:OnInboundCallReceived]
    MultiView = "All Contacts across Organizations"
    QueryBusComp = "Contact"
    QueryBusObj = "Contact"
    QuerySpec = "'Work Phone #'='650506{ANI}'"
    SingleView = "Service Contact Detail View"
    SingleLog = "LogIncomingCallContactFound"
    Log = "LogIncomingCallContactNotFound"
    MultiLog = "LogIncomingCallMultiContactFound"
    Comments = ""

If contact data is found, then the following event log updates the customer dashboard:

[EventLog:LogIncomingCallContactFound]
    AfterWork.'ACD Call Duration' = "{@WorkDuration}"
    AfterWork.'Done' = "{@Now}"
    AfterWork.'Planned Completion' = "{@Now}"
    BusComp = "Action"
    BusObj = "Contact"
    Display = "False"
    LogField.'Account Id' = "{Contact.'Account Id'}"
    LogField.'Call Id' = "{refId}"
    LogField.'Contact Id (Thin)' = "{Contact.Id}"
    LogField.'Planned' = "{@WorkStartTime}"
    LogField.'Started' = "{@WorkStartTime}"
    LogField.Description = "Inbound call"
    LogField.Type = "Call - Inbound"
    ServiceMethod = "Persistent Customer Dashboard.Update Dashboard from CTI"
    ServiceParam.Field = "Id"
    ServiceParam.Value = "{Contact.Id}"
    WorkTrackingObj.ContactId = "{Contact.Id}"
    Comments = ""

If no contact record is found, then the following event log clears the customer dashboard:

[EventLog:LogIncomingCallContactNotFound]
    AfterWork.'ACD Call Duration' = "{@WorkDuration}"
    BusComp = "Action"
    BusObj = "Contact"
    LogField.'Call Id' = "{refId}"
    LogField.Description = "Unknown Caller({ANI})"
    LogField.Type = "Call - Inbound"
    ServiceMethod = "Persistent Customer Dashboard.CleanDashBoard_UI"
    Comments = ""

If multiple contact records are found, then the following event log clears the customer dashboard:

[EventLog:LogIncomingCallMultiContactFound]
    AfterWork.'ACD Call Duration' = "{@WorkDuration}"
    BusComp = "Action"
    BusObj = "Contact"
    LogField.'Call Id' = "{refId}"
    LogField.Description = "Inbound call({ANI})"
    LogField.Type = "Call - Inbound"
    ServiceMethod = "Persistent Customer Dashboard.CleanDashBoard_UI"
    Comments = ""

Viewing Communications Status Data

System administrators and call-center administrators can display status data about agents who are engaged in communications activity in Siebel applications. Status data is displayed in:

• All Active Agent Status view

• All Channel Items view

This topic contains the following information:

• Viewing Agent Status Data

• Viewing Channel Status Data

Viewing Agent Status Data

You can use the All Active Agent Status view to view status data for each agent who is currently logged in and using a Siebel application configured to support session communications. For each agent, the view displays:

• The agent’s login, agent ID, and first and last name

• The communications configuration that is active for the agent

• The teleset the agent is using, for voice agents

• Currently active work items for the agent, for each channel

• The agent’s state (such as Ready, Not Ready) for each channel for the agent’s configuration

To view agent status data

1. Navigate to the Administration - Communications screen, then the All Active Agent Status view.

2. Click Refresh to update the displayed data.

Note: The All Active Agent Status view is always updated by the Siebel CRM system software and does not require specific parameter settings or event log definitions.

Viewing Channel Status Data

You can use the All Channel Items view to view status data about current communications work items for agents. For each work item, the view displays the:

• Work item’s channel, such as voice, email, and so on

• Channel target address

• Time the work item started

• Agent’s Siebel login, agent log, and agent password

Note: For each work item, the value displayed in the Start Time field is accurate only to the extent that the time is synchronized between the various computers running instances of Communications Session Manager or Application Object Manager.

To view channel status data

1. Navigate to the Administration - Communications screen, then the All Channel Items view.

2. Click Refresh to update the displayed data.

Modifying How Channel Status Data Is Displayed

Channel status data is logged for display in the All Channel Items view only if the UpdateChannelStatusTable configuration parameter is set to True. In communications configurations provided with Siebel Business Applications, this parameter is set to True. For more information, see Specifying Parameters for a Communications Configuration.

Note: Records in the All Channel Items view reflect current activity only. If any records persist in this view for past work items, then you might have to delete such records manually in this view.

Distributing Status Data to Agents

Call-center administrators might want to distribute call-center statistics from the switch or CTI middleware to call-center agents for display in the message broadcast area of the Siebel client. For example, it might be useful for an agent to know how long a call has been in an ACD queue before taking the call, how many calls are currently in an ACD queue, or the average talk time for a call. Consult the documentation for your switch or CTI middleware for information about how to retrieve call-center statistics.

You configure message broadcasting in the Message Broadcasts view, located in the Administration - Communications screen. For more information, see Siebel Applications Administration Guide.