Skip Navigation
Expand
Best practices for setting up an additional interface
Answer ID 1377   |   Last Review Date 04/28/2019

We want to add another interface to our site. What are some best practices for setting up our additional interface?

Environment:

Setting up multi-interface site

Resolution:

Multiple interfaces allow you to provide a separate end-user site and differing information to a variety of audiences while maintaining one knowledge base and one database.

Note: Additional interfaces are a chargable item. For more information on pricing and options, please contact your sales account manager.

Use the best practices below in conjunction with your Oracle B2C Service Project Plan. 

To access Oracle B2C Service manuals and documentation online, refer to the Documentation for Oracle B2C Service Products.

For an overview of which Service features are shared across interfaces, refer to Answer ID 2001: Shared Service Feature for Multiple Interfaces.


Identify one Project Coordinator for the Overall Knowledge Base:
Identify a single person to be responsible for the entire Oracle B2C Service application. This project coordinator may then work with the application owners of the separate interfaces to ensure the overall integrity and usability of the knowledge base.

Obtain training:
Read the chapters and documentation above which describe multiple interfaces. This is crucial step to maintaining the integrity of the entire database. Make sure ALL of your staff that will be using an interface receives training in how to use the application. 

Plan Appropriate End-User Display (Branding) for Each Interface:
The end-user pages of each interface must be configured appropriately for the Web site and for use by the target audience. This includes the interface URL, the look and feel or the site, and determining custom text to be used (i.e. custom message bases).

Plan for Multiple Language Interfaces:
When implementing an interface that will use a different language, it is critical to evaluate standards for how that language will be implemented across multiple language interfaces. Two or more countries may share a common language and may access your site; however those countries may use different codes, terminology, and standards for displaying information.
 
For example, France, Belgium, Canada, and Switzerland all use French as a main language. When publishing information to the end-user pages, simply tagging an answer to a language may not have the correct information for that country. Proper pre-planning prevents poor performance on your site.

Additionally, language packs for an interface can only be applied at the time of interface creation.  Additional information on this can be found in Answer 2486: Changing the language of an interface.

Configuring an Interface Allows Access to Other Interfaces:
Staff members tasked with the configuration of an interface will see information associated with other interfaces when they access administration features. If you have multiple staff members configuring your site with full access, it is very important that they understand they will see information pertaining to other interfaces when they log in to the administration pages.

For example, a staff member who has access to the Staff Management, Customizable Menus, and Custom Fields tables has the ability to affect staff access and visibility to all interfaces, not just their own interface. This reinforces the importance of one Project Coordinator, who can ensure that staff members are aware of what is occurring with the entire knowledge base, not just their interface.

See Service features shared across multiple interfaces for more information.

Some Information Only Configured Through the Interface:
While most features can be configured regardless of which interface you are logged in to, some items are not shared across the administration pages of the different interfaces. In these cases, you must log in to the administration pages for the interface you wish to configure.

Some Information Shared Across All Interfaces:
When administering multiple interfaces, be aware that some information is shared across interfaces and cannot be restricted by using views or profiles. For example, when an incident is proposed to become an answer, there is no Interface field to use in the answer record, so answers cannot initially be sorted by interface. Instead consider using products, categories, or custom fields to manage proposed incidents. Similarly, contacts and organizations are not noted by interface.

Define Staff Needs for Access:
A major task when configuring multiple interfaces is planning and configuring staff access. Determine what information each staff member needs to access and then configure views, profiles, and staff groups accordingly. Start by determining which information is privileged per interface. Which information does each staff member need to access? Will staff be accessing information or assigning incidents across interfaces? Test the views and profiles for the appropriate staff as you perform the configuration.

See the following for more information:
Restricting staff members from full administrative access

Determine Content of each End-user Interface:
A major planning milestone that should be led by the Project Coordinator is to determine the visibility of answers in relation to products, categories, and answer access levels per interface. This activity also helps identify labeling challenges that may arise. 

Answer 1096: Publishing different answers to different interfaces provides more information.

Define Answer Console Privileges and an Answer Publishing Process:
Determine who will be responsible for adding new content to the knowledge base. Also, define the process for how new answers will be reviewed and published. This includes defining proposal processes for staff answering incidents and publishing processes for new answers. If you have multiple interfaces in the same language, we recommend assigning one overall owner for the answers who understands which answers should be published to each interface and one owner for each interface.

Determine Business Rules Used for Each Interface:
Take the time to review your existing business rules to determine which rules are to be used with that interface. Determine if each business rule applies across all interfaces. If not, then use the IF condition in the rule to specify which interface the rule applies to.

Also consider the time zone and work hour settings for each interface and how these affect the escalation rules for your new interface. Interfaces using different languages may involve different time stamps. The configuration setting TZ_INTERFACE may need to be set for the relevant locale of the target audience using that interface.

See Best practices for setting up incident rules for more information.

Mailboxes per Language:
When allowing assistance requests to be submitted via email, create a mailbox for each language interface. For example, if a database has three interfaces, French, German, and English; create a separate mailbox for each interface. This ensures that the SmartAssistant Suggested Solutions, the receipt email message, and the response emails will be in the appropriate language. Separate mailboxes also ensure that emails are routed to the appropriate staff.

Answer 1476: Configuring mailboxes to support multiple language interfaces provides additional information.

Available Languages for this Answer:

Notify Me
The page will refresh upon submission. Any pending input will be lost.