Implementing User Management

This chapter covers the following topics:

Overview of Implementing User Management Chapter

This chapter contains information on implementing and maintaining user management and site registration functionality in Oracle iStore.

Overview of User Management

User management is the process of registering a user and thereafter maintaining the user in the system by granting or revoking privileges, accounts, customer profile information, and party relationships based on a set of business requirements. User management involves registering new users, modifying existing users, approving or rejecting user approval requests, setting up enrollments and registration templates, assigning users to business accounts, and more. For self-service registration (such as provided through Oracle iStore's Customer Application), the following two options are available for setting up roles, registration processes and system-administrator-level user maintenance:

Leveraging the above user management framework applications, you can use Oracle iStore to register users, configure registration pages, approve users, manage user profile information, and more.

This chapter discusses the capabilities and functionalities of user management within Oracle iStore, with some summarized information about using Oracle CRM System Administration Console. Other than one section on integrating with Oracle User Management (UMX), no information is provided about UMX. For complete information on utilizing the capabilities of these other user management framework application, see:

Key Terms and Definitions

This section provides key terms and definitions related to user management. Note that the functionality described here is the functionality of either Oracle iStore or Oracle CRM User Management, not that of Oracle User Management.

Integration with Oracle User Management

Oracle iStore offers support for allowing customer registration through the Oracle User Management framework.

To allow you to use Oracle User Management with Oracle iStore, the following data is supplied:

Following are high-level steps to enable registration through Oracle User Management:

  1. Set the profile option, Local Login Mask, to 127 to enable the registration feature.

  2. Create a registration process (for example, iStore Registration) in Oracle User Management.

  3. Set the profile option, UMX: Register Here Link: Default Registration Process, at server level.

In the above setup, the Register Here link takes users to an Oracle User Management central registration page. In addition, the system uses the Oracle User Management Forgot Password feature and related e-mail notification instead of Oracle iStore's own Forgot Password feature/notification. Oracle User Management is accessible by logging in as System Administrator through the AppsLocalLogin interface. For more information on Oracle User Management, see the Oracle Applications System Administrator’s Guide - Security.

User Registration Overview

Customers who wish to access Oracle iStore's Customer Application must register and be approved (if your implementation requires approval) before they have full permissions in the sites. Oracle iStore provides registration and user management screens for customer users; however, most user registration setups and associated processes are provided through a common registration and user management framework supplied by the Oracle CRM System Administrator Console.

The Oracle CRM System Administrator Console is accessible by logging into the Oracle CRM Login Servlet (JTF login) as system administrator. System administrators have the ability to configure user types, roles, enrollments, registration templates, and approval processes. See the online help accessible from the System Administrator Console for more information.

Users begin registration by selecting the Register link, and then select their user type from a list of user type choices. The user framework supports a variety of user types and approval scenarios. In addition, you can use enrollments to automatically tie specific registration data to user types.

Note: Do not use the Oracle CRM System Administrator Console to register users of Oracle iStore. Use Oracle iStore's registration pages and user management pages instead. These pages are available in the Customer Application after your setup of Oracle iStore is complete. See the section, "Registering Using Oracle iStore", for details.

Registration involves filling in personal and company data (if applicable), and then waiting for approval (if required) before accessing the Web sites. Depending upon the approval mechanisms in place, users are either automatically approved or approved by an administrative user. Note that in a multiple-approver scenario, all approvers must approve a user before he is granted access. Integration with Oracle Workflow (using both Oracle CRM Technology Foundation and Oracle iStore workflows) provides e-mail notification of user registration events and pending approvals.

User Management Integration with Other Oracle Applications

Users of Oracle iStore, Oracle iSupport, and Oracle Partner Management can attain an integrated user registration and management experience through the common registration framework and Oracle iStore's site management capabilities. These capabilities are summarized in this section. Also see the following chapters:

Common Registration Framework Benefits and Behavior

The highlights of the common registration framework are discussed below.

User Type Support Across Applications

Integrated user management across applications provides registration and support for several user types within the Oracle iStore framework. Setup of user types is performed in the Oracle CRM System Administrator Console. A table listing the seeded user types, enrollment keys, and default responsibilities and roles can be found in the topic covering user type definitions in the appendix, Seeded User Data. Following are the seeded enrollments for common user types.

These two default enrollments give B2C users the required ability to access Oracle iStore sites and Oracle iSupport via the Oracle iStore Customer UI (if the Support Site: Individual User enrollment is activated). By default, these users do not require approval. No roles are assigned to this user type, or to the enrollment, out-of-the-box.

These two default enrollments give these users permission to access Oracle iStore and Oracle iSupport as regular business users. By default, these users require approval by a primary user within their company.

These two default enrollments give these users permission to access Oracle iStore and Oracle iSupport as primary users for their companies. By default, these users do not require approval.

Note: Oracle Partner Management user types are not enabled by default. You must enable the user types in the Oracle CRM System Administrator Console. See the chapter, Integrating Oracle iStore with Oracle Partner Management, the online help available in the CRM System Administration Console, and the Oracle Partner Management Implementation Guide for details.

See this chapter's "User Type Registration Selections" section for details about the seeded Oracle iStore registration page.

Support for URL Parameters

Oracle iStore supports placing URL parameters appended to page URLs. For example, implementers can append the Oracle iSupport application ID to the end of the application entry page, ibeCZzpEntry.jsp.

ibeCZzpEntry.jsp?go=reg&app_id=672

Following are the supported parameters and their impact on functionality:

E-Mail Notifications Support

Leveraging integration with Oracle Workflow, the Oracle iStore registration framework supports several notification events which inform users via e-mail of registration events. If integrating with Oracle iSupport and/or Oracle Partner Management, the system substitutes specific Oracle CRM user management notifications for the iStore notifications. See the chapter, Integrating Oracle iStore with Oracle Workflow, for details.

Preservation of Application Context

The following application context benefits are provided to users of integrating applications:

See the chapter, Implementing Site Management, for more information.

Deep Linking Support

Deep linking from external web sites to the registration page is supported. See the deep linking information in the chapter, Advanced Display, for more information.

Support for Single Sign-On

See the chapter, Integrating Oracle iStore with Oracle Single Sign-On.

Ensuring Proper Dependency Setup for User Management

The Oracle iStore user management framework leverages the Oracle CRM Technology Foundation user management framework through the Oracle CRM System Administration Console. Therefore, you must ensure that the technology stack is properly set up before beginning user management operations. Follow the steps in the Oracle Applications CRM System Administrator's Guide , Release 11.5.10, to set up Oracle CRM Technology Foundation (or see the online help available through the System Administration Console). Also perform the setups listed in the chapter, Verify Mandatory Dependencies, and the remaining sections within this section, if your business requirements dictate.

Setting up User Registration

Customer registration for users of Oracle iStore's Customer UI is enabled by default -- however, Oracle Applications requires that the guest user password profile option be set, as outlined below. All of the other steps are optional.

Guest User Password Profile

Oracle Applications requires that the guest user password profile option be set. For Oracle iStore functionality, if this profile is not set at site level, user registration will fail. Therefore, set the profile, GUEST_USER_PWD, at site level. The value should be the username/password of a valid applications user account. It is recommended that this account is not assigned any actual responsibilities, but assigning IBE_CUSTOMER responsibility is required so that iStore can display the catalog for guest users.

Default Roles and Responsibilities

The default roles and responsibilities awarded to users who register through Oracle iStore's Customer UI are controlled through the user type definitions in the Oracle CRM System Administrator Console. For more information, see this chapter's sections: "User Type Support Across Applications", "Registering Using Oracle iStore", and "User Types Overview". Also refer to the appendix, Seeded User Data.

Sign-On Profile Options

Be sure to check the values of the following Oracle CRM user management profile options:

  1. Signon Password Length

  2. Signon Hard to Guess

  3. Signon Password Custom

These profile options can affect the restrictions that apply when users initially enter password and username information during registration.

Default Language Preference for E-Mail Notifications

A user's default language preference for e-mail notifications is set from the user's session language during registration. The user can change this default setting in the Profile, Preferences page. See the "Personal Profile Pages" section later in this chapter for more information.

Ensure Setup of Default Customer Profile Class

In order for Oracle iStore registration processes to work properly, the Customer profile class, "Default", needs to be in Active status. Setting this class to an Inactive will cause Oracle iStore registration to fail. Customer profile classes are set up in Oracle Accounts Receivable.

Additional Setup Steps

Several additional setups may be required, depending on your implementation. See the following sections within this chapter for more information:

Setting up Integrating Applications

In addition to the information found in this chapter, if integrating with Oracle iSupport or Oracle Partner Management, see the chapters, Integrating Oracle iStore with Oracle iSupport, and Integrating Oracle iStore with Oracle Partner Management, for specific user management information related to these applications.

See the appendix, Seeded User Data, for more information regarding user type definitions seeded in Oracle CRM Technology Foundation.

Setting up Account Creation

For users registering through Oracle iStore, a financial account is automatically created for them upon approval if the profile option, JTA: User Management: Automatic Account Creation, is set to Yes at site level. This is the default setting for this profile option. It is recommended that you leave this profile option set to Yes. If set to No, no account will be created for users upon approval, and thus newly approved users will not be able to log in to the Customer UI.

Note: By default, this profile option is No at Oracle iSupport application level, as users created through iSupport need not have a financial account.

In the event a user's registration is approved without an account number being assigned to him, a primary user or the system administrator can assign accounts after approval. See the section, "Account Assignment After Approval", for more information.

Setting up Approval Definitions

Oracle iStore supports the ability to launch approval processes for enrollments for its users. Enrollments and approval processes are defined in the Oracle CRM System Administration Console.

If a user registers, and the selected user type is associated to an enrollment that requires approval, a primary user needs to approve the enrollment request. Once the enrollment request is approved, the user can be assigned to the corresponding responsibility.

Note: Only after the user type registration request is approved are the pending enrollment requests shown to the primary user.

For information about seeded user data, see the appendix, Seeded User Data.

Changing Default Approval Setup

By default, the Oracle CRM System Administrator is the only user registration approver. It is recommended that you change the seeded approval process so that a primary user or users approve other B2B users within their organizations. See the online help available through the System Administration Console for more information.

In addition, as a best practice, set up an approval group to monitor and approve user registration requests. See the section, "Best Practice: Set up Approval Group", in this chapter, for more information.

See also: the sections, "Explicitly Approving B2B Users" and "Approval of Self-Registered B2B Users"

Best Practice: Set up Approval Group

Business users can be approved by:

As a best practice, it is recommended that you set up an approval group structure for user registration approvals. In an approval group, several primary users can be designated as approvers who view all of the pending approvals in the same approval queue. Following are high-level steps for setting up the approval group structure:

  1. Set up an approval group.

  2. Create a dummy user and set the approval group profile to point to the dummy user.

  3. Make the dummy user the approver for a single organization or for all of the organizations registered as customers of a Web site.

When setting up approvers for any of the Oracle iStore user types (including Oracle iSupport and Oracle Partner Management users), ensure that the FND users who have been chosen as approvers have been assigned the Oracle iStore Primary User permissions. These permissions enable approvers to access the Pending Approval page in the Oracle iStore user management pages. For a list of these permissions, refer to the appendix, Seeded User Data.

See the online help available through the System Administration Console for more information.

Set up Single Approver

If business requirements dictate that you have a single primary user as the sole approval for an organization, you may use the following high-level steps to accomplish this setup:

  1. In Oracle Forms as system administrator, create a new user (for example, create a user named DUMMYAPPROVER). Ensure that the user has been given a valid e-mail address.

  2. Set profile option, JTF_PRIMARY_USER, to the username (for example, DUMMYAPPROVER) at site level.

  3. In the Oracle CRM user management module, add the JTF_APPROVER role to DUMMYAPPROVER user.

  4. In the Oracle CRM user management module, update the JTF User Approval approval definition to use the newly created user (for example, DUMMYAPPROVER) as the default and only approver.

For more information on setting up user approvals, see the Oracle Applications System Administrator's Guide - Security.

Notifications for Approvals

E-mail notifications are automatically sent for approved or rejected user registrations. Primary users receive a notification indicating that a new user has registered in the system and has requested access. Additionally, a notification is sent to the new user to confirm that the registration is complete, but an approval is required. See the section, "Ensuring Proper Dependency Setup for User Management", within this chapter, for more information.

Setting up E-Mail Notifications for User Management

For e-mail notifications to function, you must integrate with and properly set up Oracle Workflow. See the chapter, Integrating Oracle iStore with Oracle Workflow, for Oracle iStore-specific information on this application. You also must set several notification-related profile options listed below.

Oracle CRM Technology Stack Notifications Profile Options

You must set the Oracle CRM Technology Foundation user management profile options. The following steps summarize the Oracle CRM Technology Foundation profile options that affect Oracle iStore's registration e-mail notifications functionality. Note that this section contains limited, Oracle iStore-specific information on these profile options.

  1. JTA UM Application URL (JTA_UM_APPL_URL): This profile option provides the name of the Oracle iStore application entry JSP, ibeCZzpHome.jsp, in the welcome notification sent to newly approved customers. Set this profile as follows: JSP:OA_HTML/ibeCZzpHome.jsp. Set the profile at iStore application level. The value is null by default, and a site-level takes precedence if application level is not set. Note that implementers may need to replace OA_HTML/ with the virtual directory mapped to the JSP file location.

  2. JTF_UM_APPROVAL_URL: This profile is used to display a link in the Oracle CRM Technology Foundation's registration approval e-mail notification sent to registration approvers. When an approver clicks on the link in the e-mail, after login, he is taken directly to the Pending Approval screen in Oracle iStore. Set this profile option at iStore application level to the approval login page URL, JSP:OA_HTML/ibeCAcdLogin.jsp?ref=ibeCUmdPApproval.jsp. Note that implementers may need to replace OA_HTML/ with the virtual directory mapped to the JSP file location. Implementers integrating Oracle iStore with other Oracle applications using iStore registration flow should set the profile at the appropriate product’s application level as well. For example, implementers integrating with Oracle iSupport would set the profile at iSupport application level to the above JSP value. The Oracle iStore JSP, ibeCUmdPApproval.jsp, is by default mapped to display template, STORE_UM_PENDING_APPROVAL_SUMMARY_D (which is the Pending Approvals page). Implementers who have customized this display template to point to a different JSP should provide that JSP name (in place of ibeCUmdPApproval.jsp) in the JTF_UM_APPROVAL_URL profile option.

  3. JTF_UM_MERCHANT_NAME: Set to the name of the company owning the system. This will be used in the e-mails sent out to notify customers of approval/rejection.

  4. JTA: Support Contact (JTA_UM_SUPPORT_CONTACT): Set to the name of the support contact who can be contacted by users upon registration.

  5. JTA: Sender of the email (JTA_UM_SENDER): Set to the sender of the e-mail received by users after registration; for example, set it to your company name.

  6. JTF_UM_APPROVAL_TIMEOUT_MINS: Determines the time-out in minutes used by the JTF Approval workflow before a reminder is sent to an approver or the request is rerouted to the next approver. Zero (0) means it never times out.

  7. JTF_PRIMARY_USER: Set this profile option to the value of the username which will be the universal primary approver.

Setting up Enrollments

An enrollment is a set of add-on services that users can receive during or after registration. The purpose of an enrollment is to associate with new registrants the required responsibilities, roles, enrollment approval definitions, or enrollment registration templates determined by your business needs.

Each enrollment can be associated to:

Oracle iStore supports both automatic (implicit) and explicit enrollments. Self-Service, Delegation and Self-Service-Delegation application modes are not supported.

For more information, refer to the online help available through the System Administrator Console.

Setting up Custom User Types

You can create custom user types using the Oracle CRM System Administration Console and assign the user types to roles, responsibility, and enrollments. During setup, you must associate a registration template to the user type. Further, if you create a new registration template handler, it must be coded per Oracle iStore coding guidelines. (You must refer to several seeded registration templates. Refer to Oracle.apps.ibe.um.RegisterIndividual.java used in the template, IBE_INDIVIDUAL.)

Create Custom User Type

This example creates a "Custom Business Registration" similar to Register as user of an existing organization.

  1. Create a new template, for example, CUSTOM_BUSINESS, with the following attributes:

    • Template Key --- CUSTOM_BUSINESS

    • Template Type --- USERTYPE TEMPLATE

    • Template Handler --- Create a new template handler, similar to oracle.apps.ibe.um.RegisterBusiness.java. Further, any additional custom processing can also be done here.

    • Template Name --- For example, "iStore Custom Business User"

    • Page Name --- ibeCZzpGetTemplateFile.jsp?tmp=STORE_REG_CONTAINER_D&usertype_template=STORE_REG_CREATE_CUSTOM_D where, STORE_REG_CREATE_CUSTOM_D is the programmatic access name for the registration Display Template, which is mapped to the custom registration display JSP page, coded as per requirements.

    • Sample code --- ibeCRgdBusinessCreate.jsp. Similarly, the corresponding processing page also needs to be coded. Note: iStore coding guidelines need to be followed, similar to the sample code provided.

    • Application --- iStore

    • Description --- Used to register users for existing organization (custom handler)

  2. Create a new user type, for example, IBE_CUSTOM_BUSINESS (similar to IBE_BUSINESS), with the following attributes:

    • User Type Key --- IBE_CUSTOM_BUSINESS

    • Registration Template --- iStore Custom Business User. Here, associate the new, custom registration template created above.

    • Application --- iStore

    • Approval by --- Select either No approval is required, if the users registered through this user type need not go through an approval process, or select from the approval processes available.

    • Enable self service registration --- Uncheck this option.

    Assign the desired application roles and enrollments to this user type. Assigning the user type to a responsibility is not mandatory.

  3. Set the user type as Active, and it will automatically appear in the iStore registration page without any customization.

  4. Implementers can also set up e-mail notification configurations for custom user types. For more information, see the section, "Mapping New Notification Configurations", in the chapter, Integrating Oracle iStore with Oracle Workflow.

    Depending upon whether approval is enabled/disabled for the user type, the following FND messages would be used:

    • Approval enabled --- IBE_APPRVL_REQD_CUST

    • Approval disabled --- IBE_APPRVL_NOT_REQD_CUST

    Note the above FND messages are used for all custom user types exposed through iStore.

  5. Any custom user types should also be added to the appropriate user type lookup (i.e., to IBE_UM_PRIMARY_USER_TYPES or to IBE_UM_SECONDARY_USER_TYPES). If the custom user types are not present in the applicable lookups, the registration handler will fail to distinguish the user types. Note that the same registration handler is used for both primary and non-administrative (secondary) B2B user types. For details about the lookups, see the section, "User Type Lookups", in the chapter, Implementing Messages and Prompts.

User Types Overview

User type definitions are stored and maintained through the Oracle CRM User Management Framework. In general, each user type is tied to an Oracle Applications responsibility. The default responsibility for the Oracle iStore Customer Application is IBE_CUSTOMER.

Roles can be awarded on top of the responsibilities to further control access to the HTML applications. Each HTML application usually has its own set of users within these basic user types.

For additional information, see:

Each user type in the CRM User Management Framework is associated to:

In addition, for every user type, there is a long name and a short name shown in the Oracle CRM System Administration Console. The long name displays in the Oracle iStore user type Registration listing page, and the short name displays in the Oracle iStore Pending Approval screens.

For a list of how the user types map to the links in the user type listing Registration page, see the "Site Management User Type Denitions" section in the appendix, Seeded User Data.

Oracle iStore User Types

In addition to the administrative users described in the chapter, Implementation Tasks for Oracle iStore, Oracle iStore also supports the following customer user types:

Guest Users

Oracle iStore guest users (also called walk-in users) can browse Customer UI catalogs and create shopping carts. However, they cannot:

Walk-in users who visit your specialty sites are automatically logged in with the guest user name. If a guest user makes any changes, such as modifying the preferred language or currency, or adding items to the shopping cart, the changes are saved in the cookie so that different guest users cannot see each other's changes.

See the chapter, Implementation Tasks for Oracle iStore, for details on how to implement guest user access.

B2C Users

Registered business-to-consumer (B2C) users are individual customers not associated with a company. By default in Oracle iStore, B2C users do not require approval; they are always approved automatically -- however, you can use the Oracle CRM System Administrator Console to set up B2C users to require approval.

Unlike B2B users, for B2C users, out-of-the box you cannot assign roles.

B2B Users

Business-to-business (B2B) non-administrative users represent companies whose information is stored in Oracle Trading Community Architecture (TCA). Typically, when non-primary B2B users self-register, they enter a Registry ID created when the first user from that company (the primary user) registered. All B2B user information is stored in the Oracle TCA schema.

Non-administrative B2B users are awarded the business user role by default. See the "Business User Role Seeded Permissions" section in the appendix, Seeded User Data, for a list of permissions seeded within the Oracle iStore business user role.

Primary Users

Primary users are B2B users who are responsible for creating and managing other users within their companies. Typically, the first user who registers his company in Oracle iStore is considered the primary user. When a primary user registers his organization for the first time, a Registry ID (Organization ID), a primary company financial account, and a primary company address are created in Oracle TCA. This first financial account for the company cannot be changed by the primary user. Subsequent users from the company should use the Registry ID when registering, in order to be associated to the company in Oracle TCA.

See this chapter's "Managing Business Users with Oracle iStore" section and the "Primary User Role Seeded Permissions" section within the appendix, Seeded User Data, for more information about the abilities of these users.

Reseller Users

The seeded IBE_RESELLER_ROLE is appropriate to assign to users who sell your products but are not internal to your company. If you are integrating with Oracle Quoting, Reseller Users can create shopping carts, but cannot view all customer accounts in your records, bill to anyone other than the sold-to customer, or sell to customers who are not in your records.

User Types for Integrating Applications

Oracle iStore supplies several user types in the Oracle CRM user management framework. See this chapter's "User Type Support Across Applications" section and the "Site Management User Type Definitions" section within the appendix, Seeded User Data, for details.

Registering Using Oracle iStore

When registering through Oracle iStore, to begin registering, users can select:

Users must complete the required information, and are either immediately approved or must wait for approval before accessing the Customer Application, depending upon the approval mechanisms implemented.

Implementers can specify the landing page that occurs after registration by inserting the "ref" parameter in the URL. See the "Support for URL Parameters" section within this chapter for more information.

Following registration, administrative B2B -- known as primary users -- can fulfill user management functions for their companies in Oracle iStore's Customer UI. These functions can include: approving users, creating new users, assigning accounts, resetting passwords, and awarding and managing user roles.

Note: Implementers can disable the ability for primary users to create other users by setting a profile option, APPS_SSO_USER_CREATE_UPDATE, to Disabled. See the section, "Ability to Disable User Creation", below, for more information.

Behavior When Users Get Rejected

When a user's registration request is submitted, the username entered is created in Reserved status in the Oracle Technology Foundation table (FND_USER table). Only upon approval is the username enabled in the system. If the approval is rejected, the username is released and all details of the contact are inactivated. The username is removed from the system and can be re-used by this or another user. Also, since the contact is inactive, it is not selectable to be the sold-to, bill-to, or ship-to contact by any other user, nor by sales representatives.

In addition to the above noted behavior, the system sets rejected users' Oracle TCA data to inactive. If the user is a business contact of an existing B2B organization, the party of type, contact, associated with the user is set to inactive status. If the user is the primary user of a new, registered company, both parties – organization and contact – are set to inactive, as long as there is no other contact associated to the organization. If the user is a B2C customer and is registering for the first time, the new party of type, person, is set to inactive status. Following are the specific records that are inactivated for the two main user types (B2B and B2C):

The following are exceptions to the above rules:

If the implementation requires that a user's TCA data never gets flagged as inactive, disable the subscription with IBE_JTA_INTEGRATION_GRP.postRejection as the function name. Use the following steps:

  1. Log into Oracle Self Service Web Applications as system administrator and select the responsibility, Workflow Administrator Web Applications.

  2. Navigate to Business Events and then select Events.

  3. Search for the event, oracle.apps.jtf.um.rejectUTEvent.

  4. For the above event, select Subscription.

  5. Update the subscription with IBE_JTA_INTEGRATION_GRP.postRejection as the function name.

  6. Change the status to Disabled and save the changes.

Check Username Availability

When a user registers through Oracle iStore, the system automatically checks, before registering the username, whether the username is already in use in Oracle CRM Technology Foundation (FND_USER table), Oracle Internet Directory (OID), and any other third-party application. Following is the behavior during the checks:

The following table further illustrates the behavior.

Check Username Behavior
  Username Not in FND or OID Username in FND and OID Username in FND But Not in OID Username in OID But Not in FND
Re-linking Not Allowed		 Username in OID But Not in FND
Re-linking Allowed
Self- Registration Username creation allowed; username created in FND and propagated to OID “Username already used” error message is shown “Username already used” error message is shown “Username already used” error message is shown “Username already used” error message is shown
Delegated User Management Username creation allowed; username created in FND and propagated to OID “Username already used” error message is shown “Username already used” error message is shown “Username already used” error message is shown Username creation allowed

User Type Registration Selections

The user type selection Registration page groups users into three main types:

An additional group, titled Others, displays for user types that do not match any of the above categories. This scenario may occur when a new iStore user type is introduced that is not included in any of the existing lookups that categorize the user types; in this case, the Others group automatically appears in the user type listing page, and the new user type is shown under that group.

The grouping for the three main types is achieved using the following user type lookups:

Each of the lookups shown above contains additional lookups (child lookups) that enable the specific registration links for the different user types. For example, the IBE_UM_STORE_USER_TYPES lookup contains child lookups for primary, non-administrative B2B, and Need Online Access users. The codes of the child lookups match the user type keys present in Oracle CRM user management module. The standard user types are enabled by default. To enable an additional user type, enable the user type in the Oracle CRM Technology Foundation System Administrator's Console.

For a list of the child lookups within each user type lookup, see the chapter, Implementing Messages and Prompts.

Note: While displaying the registration user type listing page, if the system returns only one user type, then the user will be directly taken to the registration page for that user type.

Following is the business flow for users selecting a user type in the registration page:

  1. The user accesses the Registration page using one of the methods described in the section, "Registering Using Oracle iStore", above.

  2. In the Registration page, users select one of the following hyperlinks (which map to the user types lookups and to user types in the Oracle CRM user management module):

    • Register as individual --- This link is for registering B2C users.

    • Register your company --- This link is for registering a company for the first time. Note that this registers a primary user for the first time. An Organization ID (Registry ID) is created. When the primary user registers his company, the company is registered as a customer of the site where he registers, and the user is created as the primary user for that organization.

    • Register as a user of an existing company --- This link is for registering a non-administrative B2B user whose company has already been registered.

    • Register as a partner --- This link is for registering an Oracle Partner Management application company that will be accessing Oracle iStore's site management functionality.

    • Register as a user of an existing partner --- This link is for registering a partner business user (a user affiliated with the Oracle Partner Management application) whose company has already been registered.

Also note the following:

The following figure shows an example of how the Registration page might look in an implementation of Oracle iStore.

Oracle iStore Registration Page Example

the picture is described in the document text

Note: The above page is shown only when the implementation is not using a Central Access Provisioning system (CAPs). If CAPs is enabled, a different page is shown. See the chapter, Integrating Oracle iStore with Oracle Single Sign-On, for more information.

Remember that the Partner registration links are inactive by default. You must activate these user types in the Oracle CRM System Administration Console. See the chapter, Integrating Oracle iStore with Oracle Partner Management, and the Oracle Partner Management Implementation Guide for more information.

User Types Listing Page Use Cases

The following use cases can aid your understanding of the Registration page behavior under various conditions. These use cases assume at least one Online Access to Existing Account user type is enabled.

Use Case 1

In this scenario, Oracle iStore is integrated with Oracle Single Sign-On Server (SSO), CAPs is disabled, and user creation/update is allowed. Since CAPs is disabled, the user type registration selection page will display all existing user types, grouped under the user type groups.

Use Case 2

In this scenario, Oracle iStore is integrated with Oracle Single Sign-On Server (SSO), CAPs is enabled, and user creation/update is not allowed. Since CAPs is enabled, the user type registration selection page will display the following:

Note that if the Online Access to Existing Account user types are disabled, the system will direct the user to the CAPs registration form.

Selective Display of User Type Links

You can set up the Registration user types listing page to show only a subset of the available user types. You can set up a site-specific user type listing or set up a deep link to a specific user type(s) registration from an external page. This functionality is achieved by using the parameter, group_ut.

Site-Specific Setup

To set up a site-specific link scenario, map the JSP, ibeCRgdRegContainer.jsp (the registration listing page), appended with the parameter, group_ut=<list of comma separated user type keys>, to the Display Template, STORE_REG_CONTAINER_D.

Example: The implementer has added a template mapping for the Display Template, STORE_REG_CONTAINER_D, which is the user type Registration listing page. The template has the following URL mapped to a Oracle Partner Management specialty site:

ibeCRgdRegContainer.jsp?group_ut=IBE_PARTNER_BUSINESS:IBE_PARTNER_PRIMARY

With this setup, when a user selects that Partner specialty site and then selects the Register link within the specialty site, the system will show only the enabled Partner user types in the Registration page.

Deep Link Setup

To set up a deep link to a specific user type(s), create the deep link in the external site, as in the following example:

http://<host>:<port>/OA_HTML/ibeCAcpSSOReg.jsp?a=b&group_ut=IBE_PARTNER_PRIMARY:IBE_INDIVIDUAL

In the above example, the Registration page would only show the Register as Individual and Register as a partner listings (grouped, of course, into the Individual and Partner areas).

Also note the following:

User Registration Information Entry Pages

This section discusses the user registration pages available with standard registration.

Individual User Registration Page

The individual user (B2C) registration page is available by selecting the Register as individual hyperlink on the Registration page. It includes the following data entry fields:

The B2C user is not required to enter address information to register.

Primary Business User Registration Page

The user registration page for primary (administrative) business users is available by selecting the Register your company hyperlink on the Registration page. It includes the following data entry fields:

Non-Administrative Business User Registration Page

The user registration page for non-administrative business users is available by selecting the Register as a user of an existing company hyperlink on the Registration page. It includes the following data entry fields:

Non-administrative business users are not required to enter address data, since the company address is related to them in Oracle TCA.

Additional Information Common to Registration Pages

Note the following additional details common to the registration pages:

Online Access to Existing Account

Merchants have the ability to offer Customer Application access to customers who already have placed an order with them through a selling channel other than Oracle iStore (e.g., through a call center). This functionality, known as Online Access to Existing Account, lets customers register for access to Oracle iStore site(s) without the need to duplicate existing accounts. Since these customers have a pre-existing business relationship with the merchant, they generally already have a financial account in Oracle TCA which Oracle iStore can use to recognize and validate them. Once registered, these customers have full access to the sites; they can place orders and view the progress of orders (even if placed through another channel).

Business Process Flow

Following is the business process flow:

  1. A B2C or B2B customer has placed an order with the merchant company through some other avenue than Oracle iStore.

  2. The customer navigates to the Oracle iStore Customer Application in order to view the status of his order or other relevant order information.

  3. Oracle iStore displays the standard user type selection page which displays additional links for Online Access to Existing Account for B2B and B2C users. The customer selects one of the links, depending upon the user type he wishes to register as.

  4. Oracle iStore displays the Online Access to Existing Account registration page that maps to the user type selected. The customer enters information which validates him as an existing customer (see the section, "User Interface Details", below, for more information). If the user is unable to enter the required information, he will not be allowed to proceed with the online access request.

  5. The user enters the required information and submits the request, which is validated and treated as follows:

    • B2C User Data Validation: The system validates the following: (1) Whether the account number is not already associated with an existing user account; (2) Whether the zip code provided is a valid billing zip code associated to the account and was used in any previously placed order; (3) Whether the phone number provided is associated with the account number; and (4) Whether the username is unique and the password valid. If any of these items cannot be validated, the system displays an error message and returns the user to the registration page.

    • B2B User Data Validation: The system validates the following: (1) Whether the account number is valid and belongs to a B2B organization, and the order was placed using the account number entered; (2) Whether the contact, who is the sold-to contact in the order, is already associated with an existing user record; (3) Whether the order date matches the order number entered; and (4) Whether the username is unique and the password valid. If any of these items cannot be validated, the system displays an error message and returns the user to the registration page. Note that for order date, the system will perform a search between one day before and one day after the order date entered by the user.

    • Username Validation for B2C: If the username is already active, the following error message is displayed: "The account information provided already has an online username. Please login." If the username is inactive, the following error message is displayed: "Your online account has been inactivated. Please contact the System Administrator to activate it."

    • Username Validation for B2B: If approval status is not Rejected and the existing username is active, the following error message is displayed: "The account information provided already has an online username. Please login." If approval status is not Rejected and the existing username is inactive, the following error message is displayed: "You already have a user account. Please contact the System Administrator or the Primary User of your organization to activate it." If the approval status is Rejected, the user can register using a different username.

    • E-Mail Address Treatment: If the e-mail address entered is not the primary e-mail address stored for the user, the system marks the newly entered e-mail address as the primary e-mail address. The system retains the demoted e-mail address.

    • Inactive User Treatment: If a B2B user is found to already exist but is inactive, he is shown a message telling him to contact the primary user of his organization. If a B2C user is found to already exist in the system but is inactive, he is shown a message telling him to contact the system administrator.

  6. If no registration approval is required, the user is logged in and shown the Customer Application default landing page. Oracle iStore sends a registration confirmation e-mail to the customer (see the chapter, Integrating Oracle iStore with Oracle Workflow, for e-mail notification details). If approval is required, the customer is shown a confirmation page and will need his registration approved before accessing the application, following standard user registration functionality.

  7. Since the candidate already possesses a financial account, the system does not create a new financial account for Online Access to Existing Account registrations.

Note: Usernames created through Online Access to Existing Account functionality are associated to sold-to contacts only.

User Interface Details

When Online Access to Existing Account functionality is enabled, the user type selection page displays two additional links, one under the Individual user section and one under the Company section. Following is the wording of the links:

Registration Pages

The registration pages are described below.

Note: The validation logic to verify the user's identity can be customized by mapping customized display and processing JSPs to STORE%PARTIAL% display template keys, as appropriate. The processing page, after successful validation, must pass the following JSP parameters: username, password, e-mail and contactid, to the forwarded JSP (jtftmplh.jsp), where, contactid is the validated party_id of type, person (for B2C), and the validated party_id of type, party_relationship (for B2B).

Individual (B2C) Registration Page

The Registration For Individual Customer page displays after a customer selects the Need Online Access individual link. In this screen, the customer must enter the following information used for validating his customer status:

Company (B2B) Registration Page

The Registration For User of An Existing Company page displays after a customer selects the Need Online Access company link. In this screen, the customer must enter the following information used for validating his customer status:

In each of the screens, the customers are given the option to opt-in/opt-out of marketing materials being sent to them.

User Management Assumptions

With Online Access to Existing Account functionality, the following general user management assumptions are made:

Entities Required for Different User Types

The following table show the entities required for Oracle iStore individual (B2C) user types:

Entities Required for Oracle iStore B2C User Types
Individual User: B2C Entities Required? Comments
Active Username Yes If username is end-dated, an error will display.
Active Person Party (i.e., an active record in hz_parties table with party_type as ‘PERSON’) Yes If this record does not exist, the user will have to do partial registration. If a party record exists but is inactive, an error message is shown.
Record in Oracle CRM Technology Foundation (JTA) registration table (jtf_um_usertype_reg) for this user Conditional If the logged-in user has all of the above entities as valid or active, then:

  • If this record does not exist OR the record exists with Approved status (status is approved, and the effective end-date is either blank or set to a future date), the user can complete his login (no partial registration needed).

  • If this record exists, but is in Rejected status, the user can browse public sites; if he attempts to access a restricted site or a secure page (e.g., Profile or checkout), he will be taken to the partial registration screen, where he will be required to re-confirm his registration information again and re-submit his request to access iStore again.

The following table shows the entities required for Oracle iStore organization (B2B) user types (includes Oracle Partner Management user types):

Entities Required for Oracle iStore B2B User Types
Individual User: B2B Entities Required? Comments
Active Username Yes If username is end-dated, an error will display.
Active B2B related TCA records (i.e., active records in hz_parties, hz_relationship tables, which identify and associate the B2B contact to his organization) Yes

  • If any of these records does not exist, the user will have to do partial registration.

  • If these records exist, but any of them are inactive, an error will display.
Active Oracle TCA Account (i.e., active record in hz_cust_account_roles table for this party) Yes If this record does not exist OR exists but is inactive, the user will have to do partial registration.
Record in Oracle CRM Technology Foundation (JTA) registration table (jtf_um_usertype_reg) for this user Conditional If the logged-in user has all of the above entities as valid or active, then:

  • If this record does not exist OR the record exists with Approved status (status is approved, and the effective end-date is either blank or set to a future date), the user can complete his login (no partial registration needed).

  • If this record exists, but is in Rejected status, the user can browse public sites; if he attempts to access a restricted site or a secure page (e.g., Profile or checkout), he will be taken to the partial registration screen, where he will be required to re-confirm his registration information again and re-submit his request to access iStore again.
Partner Profile for the Company Yes This association is essential for the Organization to be treated as a Partner Company.
Permission PV_PARTNER_USER Conditional This permission determines whether the logged-in user is identified as a “partner business user” (if permission assigned) or “B2B business user” (permission not assigned)

Implementing Online Access to Existing Account Functionality

To implement Online Access to Existing Account functionality, you must enable the appropriate user types in the Oracle CRM System Administrator's Console user management module. Following are the user types that must be enabled:

For more information on the text lookups that correspond to these user types, see the chapter, Implementing Messages and Prompts. For more information on user data, see the appendix, Seeded User Data. For information on Oracle CRM System Administrator's Console, see the online help available through the System Administrator Console

Note that Online Access to Existing Account functionality is disabled when a Centralized Account Provisioning system (CAPs) is being used and the profile option, APPS_SSO_USER_CREATE_UPDATE, is Disabled.

Partial Registration

Partial Registration allows users who are incomplete from an Oracle iStore perspective to complete registration and gain access to the sites. With Partial Registration, users who do not have an account or party associated with them can access Oracle iStore sites after entering some user data and having it validated. These users may have been created through some other avenue integrated with the Oracle E-Business Suite (e.g., through a Central Access Provisioning system used with the Oracle Single Sign-On Server) and may only have a username associated with them.

Before going through Partial Registration, these users can only perform guest user activities with in the Oracle iStore Customer Application (e.g., browse the catalog, add items to the cart); when they attempt to perform some activity that requires login (e.g., check out), they will be shown one of the user types corresponding to their user status. The user then selects the appropriate user type and registers for full access to the Customer Application.

Partial registration can be used in an implementation integrated with the Oracle Single Sign-On (SSO) Server or used in a non-SSO scenario. It is applicable to B2B, B2C, and Partner users.

Partial Registration Process Flow

Following is the process flow for Partial Registration. This flow assumes a Central Access Provisioning system (CAPs) is not being used.

As a prerequisite, a customer has been registered with a username in the Oracle Internet Directory (OID) or Oracle Technology Foundation (FND) tables. Additionally, it is assumed that the user data synchronization Oracle E-Business Suite and OID has been setup appropriately.

  1. An authenticated (logged in) user approaches the Oracle iStore Customer application and browses the catalog. He attempts to perform a secure activity, such as checking out.

  2. The system checks the user session to gather user information associated with the user, such as whether he is a B2C user, a Partner user, etc.

  3. Based on the user information gathered, the system displays the user registration page with the appropriate links showing (see "User Interface Details", below).

  4. The user selects one of the user types. The Confirm Registration page displays, with known user data pre-populated into the registration form. The user enters the remaining registration data.

  5. The user submits the registration request. If auto-approval is being used, the user is taken to the page he was attempting to access before the system invoked Partial Registration. If his registration requires approval, he is shown the pending approval page and must wait for approval before accessing secure areas of the sites.

If a user's account is later revoked, he will be directed again to the Partial Registration flow.

User Interface Details

When Partial Registration functionality is enabled, the user type selection page displays different user type selection links depending upon the known user data (e.g., which type of party, if any, is associated with the user, or if the user has any Oracle Partner Management responsibilities). The following table shows the behavior.

Registration User Type Selection Page Behavior with Partial Registration
Known User Data Link(s) Displayed
User with no party or B2C user All user type links
B2B user of a B2B company B2B non-administrative and Partner primary links
B2B user of a Partner company B2B non-administrative and Partner non-administrative links
Partner user of a Partner company Partner non-administrative links

Just as with other types of registration, each link on the Partial Registration screen is associated to a specific user type in the Oracle CRM System Administration user management console.

Confirm Registration Screen

With Partial Registration, customers enter their registration data in the Confirm Registration screen.

Partial Registration E-Mail Notification Behavior

The following tables show which content is displayed in the Oracle Workflow e-mail notifications with Partial Registration, when registration is set to either automatic approval or to require approval. The first table is for standard registration; the second and third tables, presented for comparison purposes, are for delegated user creation (e.g., when a primary user creates a user in the iStore user management pages). The last table shows the Partial Registration e-mail information.

Regular Registration with SSO Disabled or Enabled: Username Does Not Exist in OID or FND
Approval Approval Required Section Approval Not Required Section User Credentials Section User Credentials Section with Username Only
Required Y N Y N
Automatic N Y Y N
Delegated User Creation with SSO Disabled or Enabled: Username Does Not Exist in OID or FND
Approval Approval Required Section Approval Not Required Section User Credentials Section User Credentials Section with Username Only
Required Y N Y N
Automatic N Y Y N
Delegated User Creation with SSO Enabled: Username Exists in OID (username relinked)
Approval Approval Required Section Approval Not Required Section User Credentials Section User Credentials Section with Username Only
Required Y N N Y
Automatic N Y N Y
Partial Registration
Approval Approval Required Section Approval Not Required Section User Credentials Section User Credentials Section with Username Only
Required Y N N Y
Automatic N Y N Y

Implementing Partial Registration

Assuming the user types are enabled in the Oracle CRM System Administration Console, Partial Registration is already set up for use in your sites.

Ability to Disable User Creation

With the existence of a Central Access Provisioning system (CAPs), or for some other business reason, it may not be necessary to allow the creation or updating of users by primary users in the Customer Application. Implementers can disable the ability of primary users to create other users by setting the profile option, APPS_SSO_USER_CREATE_UPDATE, to Disabled. When this profile option is set to Disabled, the following occurs in Oracle iStore:

See the Oracle CRM System Administrator’s Guidefor more information about the profile option.

Logging in Through Oracle iStore

Oracle iStore leverages a common Oracle Technology Foundation login screen where users can enter their usernames and passwords to access the Customer Application. The Login page is displayed under the following circumstances:

The Login page displays the user name field, a password field, a Login button, a link to the forgot password feature, and a link to the new user registration page.

For information on the forgot password feature, see the "Setting up Self-Service Login Assistance" section within this chapter.

Password Expiration

If a user attempts to log in and his password is expired, the Reset Password screen is launched.

An error message is displayed when the following information is invalid:

Error messages may contain a reference code that the merchant can use to identify the problem.

Opting In/Opting Out

Oracle iStore users can choose whether or not to receive marketing communications based on their registration with Oracle iStore. Users can specify their preference at registration and modify it later in their Profile, Preferences menu.

The opt out state is assumed unless a user explicitly opts in by selecting the Please send me e-mail about special offers and products checkbox and saving the preference (updating the page).

Opt in/opt out preferences are stored at the party level (party_id in TCA schema), using the table, HZ_CONTACT_PREFERENCES.

Opt In/Opt Out Checkbox

In Oracle iStore, there are two locations where users can select opt in/opt out preferences:

In addition, primary users can update users' marketing opt-in/opt-out preferences in the user management screens.

By default, the opt in/opt out preference checkbox always is unchecked.

The label on the opt in/opt checkbox is Please send me e-mail about special offers and products, which has the AOL message key, IBE_PREF_OPT_IN_OUT.

Table Entry with Explicit User Behavior

Following is the opt in/opt out action in the HZ_CONTACT_PREFERENCES table, according to specific actions on the part of the user:

Managing Business Users with Oracle iStore

This section contains information for managing B2B users in the Customer Application.

B2B User Management Overview

In a typical setup, primary users manage other business users in their companies. Access to all of the user management screens is provided within the Profile, Administration pages. The Administration screens support the following functionality:

This functionality leverages Oracle TCA schema and the Oracle CRM Technology Foundation user management framework.

Contact and user management functionality provides primary users of a company with the ability to search contacts and users, create contacts and users for their companies, assign roles and sites that have access restricted by responsibilities, and assign accounts for users within their company. If you are integrating Oracle iStore with Oracle Partner Management, partner primary users can define partner profile attributes for a contact.

Both primary and non-primary users can self-register themselves. Once a user has registered, depending on the user type, an approval task will be generated and assigned to an approver. The approver is notified through Oracle Workflow that there are users that require approval. For a list of notification events related to registration, see the chapter, Integrating Oracle iStore with Oracle Workflow.

Primary users utilize the Pending Approvals page within the Customer Application Administration menu to approve and reject user registration requests for their companies. If a primary user is a part of an approval group, he will see all pending approvals within his approval group. Once all required approvals are granted, the user is notified via e-mail and given access to the system.

B2B User Registration Approval Options

In the Oracle CRM System Administration Console, implementers can set up B2B user registration to require approval or not. Whether or not a user is automatically approved depends on the Approval by flag in the user type definition. In the sysadmin console, the Approval by flag can be set to:

If you have set up B2B registration to require approval, then these users must be explicitly approved. Typically, a primary user (or multiple primary users) from the B2B user's company submits the approvals in the Oracle iStore user management pages.

New B2B users created by a primary user from the Contact Management screens will be automatically approved, if one of the below is true:

When a user's registration request is submitted, the username entered is created in Pending status in the Oracle Technology Foundation tables (FND_USER table). Only upon approval is the username enabled in the system. Upon rejection, the username is removed from the system and can be re-used by this or another user. However, if a Partial Registration request is rejected, the username is not removed, nor is the user's contact information inactivated. If an Online Access to Existing Account user is rejected, the username alone is removed; the user's contact details will remain active.

For additional setup information, see the section, "Ensuring Proper Dependency Setup for User Management", within this chapter.

Users also can be created in the Oracle CRM System Administrator Console. See the online help available through the System Administrator Console for details.

Mandating Company Phone Number During Registration

Implementers can mandate that a business phone number is required when users are registered or a contact is created by setting the profile option, IBE: Mandate Contact Business Phone, to Yes. If the profile option is Yes, the company phone number is required in all of the user management screens that relate to registering, creating, or updating contacts and users. It is also mandated on all self-registration screens in the Customer Application. Relevant fields will be marked with an asterisk (*). See the appendix, Profile Options, for more information on the profile settings.

Self-Registration Steps for B2B Users

Non-administrative and primary B2B users can use the steps below to self-register using Oracle iStore's registration pages.

For Oracle Partner Management steps, see the Oracle Partner Management documentation and the chapter, Integrating Oracle iStore with Oracle Partner Management.

Note that this flow is the default setup for B2B users registering through Oracle iStore framework. See the section, "Ensuring Proper Dependency Setup for User Management", within this chapter, for information about changing the default configuration.

In the following flow, it is assumed that a Central Account Provisioning system (CAPs) is not implemented. For more information on registration in the event of a CAPs, see the chapter, Integrating Oracle iStore with Oracle Single Sign-On.

Steps

  1. The user navigates to the Registration page via one of the methods described in the section, "Registering Using Oracle iStore".

  2. The user selects the appropriate registration link, as described in the section, "User Type Registration Selections".

  3. The user fills in the required registration data.

  4. Optionally, the user checks the Opt In/Opt Out checkbox, Please send me e-mail about special offers and products.

  5. The user submits the registration request. Subsequent activities are different for non-administrative and primary users:

    • For non-administrative users: Both the primary user for the registering user's company and the user himself receive an e-mail notifying them of the registration request. The primary user's e-mail informs him that the user has requested registration and needs approval or rejection. The registering user's e-mail informs him that his request has been received.

      At this point, the user still needs to be approved before he has any access to the Customer Application. The primary user for the user's company can follow the steps in the section, "Approval of Self-Registered B2B Users", to approve or reject the user.

      Following approval, the B2B user receives another e-mail notification informing him that his approval has occurred. If his registration has been rejected, he also receives an e-mail notifying him.

    • For primary users: By default, when this user submits his registration request he is automatically approved and immediately has full primary user permissions in the Customer Application.

      Upon approval, a new Registry ID is created for the primary user's company in Oracle TCA schema. To find out his Registry ID, he can log into the Customer Application and navigate to Profile, Company Profile. The Registry ID is also sent to the primary user by e-mail, in the registration confirmation.

      A new financial account also is generated for the primary user's company. To find financial accounts available for use, he can navigate to Profile, My Profile, Accounts.

      The primary user receives an e-mail notification about his approved registration.

Oracle iStore B2B User Roles

In the context of Oracle iStore, roles typically apply only to B2B users. B2B users can be either regular B2B or primary B2B users (unless integrating with Oracle Partner Management, in which case you may have partner regular and primary users; or if integrating with Oracle iSupport, similarly you may have iSupport regular and primary business users). Primary users have administrative abilities, including user management permissions and the ability to update company details in the profile pages. Regular B2B users have view-only permissions in the company Profile pages.

See the appendix, Seeded User Data, for a list of seeded roles and permissions.

If the seeded B2B user roles do not meet your business needs, you can create new roles with any combination of permissions.

Overview of Primary Users and the User Management Pages

Oracle iStore primary users can use the Contact Management and Role Management pages within the Customer UI Profile, Administration menu to create and manage users within their companies.

Rules Regarding Primary User Abilities:

Note: The following rules will not apply, of course, if you have customized your setup to support a primary super-user charged with managing users across organizations.

Pending Approvals Page

The Pending Approvals page allows primary users to:

The pending approval table displays the following information:

Approval Types

Approvals displaying in the Pending Approvals page will be one of two types:

Note: Enrollment requests are not shown until the user registration request is approved.

Conditions for Approving Users

Following are the conditions for the approvals to display in the Pending Approvals page:

  1. Pending approvals display in the Pending Approvals based on the following criteria:

    • Only display approvals assigned to the logged in primary user.

    • Only display approvals of the same company as the logged in primary user.

    • If Approval Groups are being used, only display approvals assigned to the Approval Group (filtered by user's company) of which the logged in user is a part, and only if the user has JTF_PRIMARY_USER_SUMMARY permission. Out-of-the-box, the iStore primary user enrollment already is seeded with a role containing this permission. See the section, "Best Practice: Set up Approval Group", for more information.

    • If Approval Groups are being used, in addition -- if there are any approvals assigned directly to the user -- these are also displayed.

  2. Primary users can approve user registrations and enrollments only if they are defined as approvers for their companies, for the approvals defined at the user type and enrollment level.

  3. Primary users only have access to the Pending Approvals screen if they are associated to the permission, IBE_INT_PENDING_APPROVAL.

Account Assignment During Approval

When approving users, if the user does not already have an account, by default, the system will generate an account for the user, in case of B2C users; in the case of B2B users, a new account is created for the organization, and further, account roles are created for the user. The primary user also can assign additional accounts to the user. Oracle iStore also allows primary users to remove accounts from users. See the section, "Approving B2B Users Who Have Self-Registered", for more information.

For information on assigning or removing accounts for B2B users in a post-approval scenario, see the sections, "Account Assignment After Approval" and "Removing Accounts from Users".

For registration rejection information, see the "Rejecting a Request" section, below.

Approving B2B Users Who Have Self-Registered

To approve users:

  1. Primary users sign in to the Administration page available within the Profile menu of the Customer Application (the user may first need to select a specialty site to access this menu). The Pending Approvals page lists pending user registration and enrollment requests in the Requests Summary table. Note that the Requests Summary table displays only requests that are associated to an approval process that the primary user has been assigned to. If the user belongs to an approval group, then pending approvals for the group also are displayed.

  2. To approve a user request, the primary user first selects the request and presses the Approve button. This retrieves the Submit Approval Request page, which shows the user's information at the top and a list of available account numbers down below. The primary user can enter comments and associate the user with one or more financial accounts before submitting the request. If the request type is an enrollment, the Submit Approve Request page displays the appropriate enrollment information instead of user information.

    • Note: In the Approve Request page, the primary user can enter comments into the Comments textbox. In the case of an established approval hierarchy, if this user has already been approved by a different approver, the last approver's comments are displayed. If no hierarchy is set up, then no comments by other users are shown.

  3. Once the primary user submits the approval, a confirmation message is displayed (if other approvers are required, a message displays to this effect) and the primary user is shown the Update User page, where he can continue to modify details about this user, including updating contact information and passwords and assigning roles, accounts, and site access. If there are multiple approvers, the system will display to the primary user the Update User page with a message indicating that the user request still needs to be approved by other users; in this case, the approval status will remain as pending in Update User page.

  4. If the approval is for a user registration, the user is created and an e-mail sent to the user notifying him of his approval. If the approval is for an enrollment, the parameters defined in the enrollment are accomplished, and the primary user(s) are e-mailed about the approval.

Rejecting a Request

To reject a pending request, in the Pending Approvals page, the primary user selects the radio button of the applicable request and then presses the Reject button. This retrieves the Reject Request page, which displays relevant user information (e.g., name, e-mail address) at the top and a Comments textbox down below. Any information the primary user enters into the Comments textbox is included in the e-mail notification sent to the user.

Upon rejection, the request is removed from the pending requests queue. However, the user still shows up as a contact in the Contact Management page.

Contact Management Page

The Contact Management page within the Profile, Administration menu allows a primary user to perform the following tasks:

Note that in a typical implementation, primary users can only view and modify users within their own organization. The Contact Management page displays all users who are parties belonging to the relationship types "contact of" and "employee of" for the primary user's company.

The Contact Management page presents user and contact information in the Contacts Summary table:

Note: In the case of Oracle Partner Management integration, a link to the Partner Profile for partner contacts and users is provided. Primary users can use the pages within this link to associate the user to a partner profile. The link to Oracle Partner Management is shown only when a Contact is selected and the Update Contact/User page is displayed.

Searching for Contacts and Users

In the Contact Management page, primary users can search for contacts and users with their companies. Following are the search options:

Note that primary users cannot find their own usernames, etc., in the search mechanism.

Creating Contacts

Primary users select the Create Contact button in the Contact Management page to access the Create Contact page where the can create a contact. Following are the data entry fields in this page:

To register the contact as a user, the primary user would select Yes under Do you want to register this contact as a user?. See the "Creating B2B Users" section, below, for more information.

Updating User and Contact Details

In the Contact Management page, primary users can select the Update icon for a specific use or contact to update details for that person. Following is the information the primary user can update:

Creating B2B Users

Primary users can create new B2B contacts for their companies, if they have the IBE_INT_MANAGE_CONTACT permission in their user role.

For a list of permissions, see the appendix, Seeded User Data.

The primary user has the option of creating a contact or a user. A contact is characterized by contact information only; no username, password, roles, or responsibilities are awarded. When a user is created (with username and password defined), the party ID of the company is associated with an FND_USER. In Oracle TCA, contacts and users are created with an "employee of" relationship type of the primary user's company.

Steps

  1. The primary user signs in to the Customer Application and selects a specialty site.

  2. The primary user selects Profile, then Administration to retrieve the Contact Management page.

  3. The primary user selects Create Contact.

  4. The primary user enters the contact information.

  5. Depending upon whether he is creating a contact or a user, the primary user selects either Yes or No for the option, Do you want to register this contact as a user?

  6. If creating a contact, the primary user selects No and then selects Apply to save changes.

    Note: To convert a contact to a user, the primary user accesses the Update icon for the user and follows the steps below.

  7. If creating a user, the primary user selects Yes and then fills in the user information in the Registration area of the Update Contact page:

    • User Type: The administrative user selects either Administrator or Business user. When a primary user create a new user with the Administrator user type, the new user receives the standard privileges of this user, as defined by your implementation.

      Note that the user types displayed in this page come from the extensible user type lookup, IBE_UM_STORE_USER_TYPES (if the primary user is a B2B user) or IBE_UM_PARTNER_USER_TYPES (if the primary user is a Partner user). An exception to this rule is that Need Online Access user type lookups are filtered out of the page. If you create custom user types, you can link them to the lookup and display the user type in this page, so that the primary user can also select the custom user type for the new user, and, therefore, assign the corresponding responsibilities and roles to the user. See the chapter, Implementing Messages and Prompts, chapter for the lookup seeded values.

    • Username: Username should be unique across all users, whether or not they belong to the same B2B organization.

    • Password: When a user is created, the password is set to immediately expire. When the new user logs in, he will be prompted to reset his password.

    • Primary Account: The primary user selects the primary account for the new user. If only one account is associated with the company, then only one account will display in the LOV.

    • Default Currency: Default Currency appears for partner users only. This field defines the default currency displayed in the opportunities summary tables.

    • Start Date and End Date: Start Date defaults to system date. End Date is optional. Note that a username can be end-dated and the contact associated with the record can still be active. Users cannot log in using end-dated usernames. If the selected user type requires approval, until the user is approved, start date and end date are set to GMISS_DATE; in this case, the user cannot log in until approved.

      Note that the primary user can choose to inactivate the contact and continue creating the user. The user will not be allowed to log in as long as his status is Inactive.

  8. The primary user selects Apply to save the changes. The user is automatically approved (if the implementation is set up for auto-approval), and an account number is assigned to him based on the primary account of the primary user. The default business user role and customer responsibility are assigned to the new user. The creation of the user generates the new user approval notification e-mail for the user; the approval e-mail displays username and password. If there are still other approvers above the current, logged-in primary user in the approval hierarchy setup, the new user created will still be pending for approval by the approvers in the hierarchy.

    The user will be asked to enter a new password on attempting to access the Customer UI areas which require sign-in.

  9. If Oracle Partner Management is implemented: The partner primary user can select View Profile to launch the partner profile page, where Partner primary users can view and update the contact partner attributes. This button is displayed only if a contact belongs to a partner company and is a primary user for the partner company.

    Important: In the case of Oracle Partner Management integration where the user belongs to a partner company, the user must also be created as a CRM Resource. This is required to have this user recognized in the Oracle Sales framework. The Resource needs to be assigned to a Resource role, and the partner contact Resource needs to be defined as member of the partner company group. To achieve this automatically, Oracle iStore calls an Oracle Partner Management API; there is no need to do this manually.

For more information on setting up user approval functionality, refer to the following sections within this chapter:

Assigning Roles to B2B Users

Since the default business user role is automatically assigned when a B2B user is approved, then this procedure would be used to add additional roles to a user. Be sure the primary user granting the roles also has the new roles himself.

Steps

  1. The primary user signs in to the Customer UI and selects a specialty site. He navigates to Profile, then selects Administration.

  2. In the Contact Management page, the primary user selects the Update icon for the user, and then he selects Roles, Assign Roles.

    Note that the roles available for assignment are limited to those not yet assigned to the user but already assigned to the primary user.

  3. After marking the desired roles for selection, the primary user presses Select. The user to whom the roles are awarded can immediately utilize those roles.

Note that additional custom roles also can be removed from B2B users, as well as deleted from the application.

Assigning Sites to B2B Users

Primary users can associate other users in their companies to Oracle iStore sites. The sites that a user is associated with initially depend upon the responsibility associated to his user type and sites that have already been restricted by responsibility --- when a site responsibility and a user's responsibility match during registration, the user is assigned to the site.

The permission IBE_ASSIGN_SITES controls the appearance of this functionality. Partner primary users are not assigned this permission, since Partner Management does not allow manual assignment of sites access, because they assign responsibility programmatically through partner memberships.

Steps

  1. The primary user signs in to the Customer UI and selects a specialty site. He navigates to Profile, and then selects Administration.

  2. In the Contact Management page, the user selects the Update icon for the user, then selects Sites, Assign Access to launch the Select Sites page, where the primary user can view a list of candidate sites.

  3. After marking the desired sites for selection, the primary user presses Select to apply the assignments.

The following rules apply when assigning sites:

Account Assignment After Approval

Account creation is not explicitly supported in Oracle iStore. No user can create accounts. Accounts are automatically generated by default, when users are approved. Primary users assign accounts to business users at approval time or through the Contact Management screens after approval.

Note: The primary user can assign all accounts for his company, even if the accounts are not assigned to him.

Use the following steps to assign accounts to Oracle iStore B2B users after approval.

For steps to assign accounts during approval, see the sections, "Account Assignment During Approval" and "Approving B2B Users Who Have Self-Registered".

Steps

  1. The primary user signs in to the Customer UI and selects a specialty site. He navigates to Profile, and then selects Administration.

  2. In the Contact Management page, the primary user selects the Update icon for the user, then selects Accounts, Assign Accounts. The accounts displayed are all those available and active for the company. The primary user will not be able to select account numbers already assigned to the user.

  3. After marking the desired accounts for selection, the primary user presses Select to apply the selection.

Note that a user must possesses at least one account number to complete transactions.

Removing Accounts from Users

To remove accounts from users within his organization, the primary user can do the following:

  1. The primary user signs in to the Customer UI and selects a specialty site. He navigates to Profile, and then selects Administration.

  2. In the Contact Management page, the primary user selects the Update icon for the user, then selects Accounts. All assigned accounts display for the user.

  3. To remove an account, the primary user selects the Remove icon for the account number. A warning message is displayed, the primary user must confirm the remove action.

Role Management Page

The Role Management pages let primary users:

Creating and Updating Custom Roles

Primary users can create new roles and assign permissions to these roles. Following are points of behavior:

Steps

  1. The primary user signs in to the Customer UI and selects a specialty site. He navigates to Profile, Administration, Role Management, Create Role.

  2. The primary user enters a name for the role, optionally enters a description, and moves the desired permissions to the Assigned Permissions window.

    Note that only those permissions assigned to the primary user will be available for him to select. For a complete list of permissions, see the appendix, Seeded User Data.

  3. The primary user selects the Apply button to save the changes. A confirmation message is displayed.

Removing Roles from Users

To remove roles from users within his organization, the primary user can do the following:

  1. The primary user signs in to the Customer UI and selects a specialty site. He navigates to Profile, and then selects Administration.

  2. In the Contact Management page, the primary user selects the Update icon for the user, then selects Roles. All assigned roles display for the user.

  3. To remove a role, the primary user selects the Revoke icon for the role. Note that no warning is given before the revoke action.

User and Company Profile Management Overview

User and company information (for example, names, addresses, and phone numbers) is stored in the profile pages of the Oracle iStore Customer UI. Profile pages allow users to view, change, and maintain their user information. In the case of B2B users, access to their company's profile pages allows them to view organizational information, such as Organization ID/Registry ID, web site address, annual revenue, and a list of administrators -- and primary users of the company are allowed to update such data.

Profile page data is stored on the back-end in the Oracle customer model, Oracle TCA.

B2B access to many of the profile pages can be controlled through permissions within a user's role. See the section, "Configuring Profile Menus", within this chapter, for more information.

Note: By default, any user registering using Register as individual, Register your company, and Register as a user of an existing company user types will receive the same level of Profile page permissions in Oracle iStore.

Integration with Other Oracle Applications

Two important aspects of the profile pages are their consistent look and feel between integrating applications and their ability to be configurable by application. For example, if you are integrating Oracle iStore with Oracle iSupport and/or Oracle Partner Management, your end-users' profile pages will access a common set of screens provide by Oracle iStore, plus allow you to customize your own display of a subset of the profile screens. This customization ability is provided through Oracle iStore Template Manager -- since each profile page is derived from an Oracle iStore template, you can configure the display of the profile pages to suit your business needs.

For users of the integrating applications, the profile pages present and allow updating of personal and company information whether the users are logged into Oracle iStore, Oracle iSupport, or Oracle Partner Management.

Personal Profile Pages

This section contains information about the personal profile pages accessible through the Profile navigation icon.

Note: All information in this section related to storage of Oracle TCA data is relevant only to B2B users. B2C users' information is always stored at the person party ID level.

Personal Information Profile Page

Within the Details link of the Personal Information page, users can record and update their own personal details, including:

Note on SSO Integration: If Oracle Single Sign-On (SSO) is enabled, this page will only display and allow update of the user's name and e-mail address -- password reset is provided through SSO; see the chapter, "Integrating Oracle iStore with Oracle Single Sign-On", for more information.

Note on Partner Management Integration: If integrated with Oracle Partner Management, two submenus display within the Personal Information page: Details and Profile. The Details page contains the functionality listed above, while the Profile page allows partners to update their profiles. The Profile link is enabled only for users possessing the required permissions (for example, those belonging to a partner company and associated to a partner profile).

Contact Information Profile Page

The Contact Information page contains three submenus: Address Book, Email Address, and Phone Book:

Note on Address Usages: Oracle iStore supports only creating billing or shipping address usage types; however, other usages created in other applications (for example, a delivery address) will display and show their correct usage in Oracle iStore. Users can identify whether an address is preferred for that usage or not.

Payment Book Profile Page

In the Payment Book, users can create, update, and delete preferred credit card information. Oracle iStore validates the credit card information upon entry. The preferred credit card is used in defaulting in the checkout phase. Credit card information is stored in Oracle Payments schema, in the IBY_SECURITY_SEGMENTS table. Credit cards potentially can be organization-striped. If a user deletes a credit card marked as primary and then creates a new credit card, the new card number will be marked as primary automatically. The iStore user must turn off encryption and then switch it on to obtain the credit card information.

Accounts Profile Page

Oracle iStore supports multiple financial accounts per user, which can be viewed in the Accounts page. Users also can see and switch accounts in the Welcome Bin in the Customer UI. Only active accounts assigned to the user are displayed, as stored in the HZ_CUST_ACCOUNTS table.

Oracle iStore allows users to set a primary account in the Accounts page. The primary account is used as the default account for any transactions performed in the Customer UI. If the customer does not explicitly assign a primary account, then the account used as primary will be the account assigned during registration, with the first account number created taking precedence.

The account used during a user's session is called the session account. B2B users with multiple accounts can switch session accounts in the Customer UI pages through the Welcome Bin. Switching session accounts can allow a customer to complete and view transactions associated to other accounts. The session account for a B2B user is used at checkout and in viewing order details. However, even if an account number is used by the application as the account number for the user's login session, the user still must explicitly mark an account number as primary before it will be stored in TCA as the user's primary account number.

Note that because they do not have multiple accounts, B2C users will not see the Accounts page, nor will they be able to switch accounts in the Welcome Bin.

Preferences Profile Page

The Preferences page allows users to set communication preferences, orders preferences, and more.

Important: The Preferences page may include links to Sales and Support pages, if integrating with Oracle iSupport or Oracle Partner Management, and the user has the required permissions.

Following are the Preferences pages:

General Preferences --- This link always displays, regardless of any integration with other applications. The following options are available:

Order Preferences --- This link always displays, regardless of any integration with other applications. The following options are available:

Company Profile Pages

This section describes the company profile pages accessible through the Profile navigation icon.

Note that in the case of integration with Oracle iSupport or Oracle Partner Management, B2B and partner users can access the same company profile screens, whether logging in from iStore, iSupport, or Partner Management.

Note: All information in this section related to storage of Oracle TCA data is relevant only to B2B users. B2C users' information is always stored at the person party ID level.

Company Information Page

Business and partner users (if Oracle Partner Management is integrated) can view company details in this page, if they have the permission IBE_INT_ORG_DETAILS in their user role.

Note that B2B users with the IBE_INT_UPDATE_ORG_DETAILS permission in their user roles can also update the company details information.

The following is displayed for company information:

Important: In the case of integration with Oracle Partner Management, the Profile link also appears, allowing access to partner profile attributes. (Partner profile attributes are configurable at implementation time; see the Oracle Partner Management documentation for details.) B2B and partner primary users can update the company details and the partner profile attributes if assigned the appropriate permission. Non-primary users should not be assigned this permission.

Contact Information Page

In the Contact Information page, business and partner users (if Oracle Partner Management is integrated) can view the company address book, e-mail addresses, phone numbers, and telex numbers.

Notes Regarding This Functionality:

Contact information includes:

Note that e-mail addresses created for B2B users are not the same as those created for a company.

Administrators Page

Business and partner users can view the list of their company administrators, if they have the permission IBE_INT_ADMINISTRATORS. The list of administrators includes only those users who are primary users of a company.

Channel Team Page

Partner users can view the list of channel managers assigned to their companies, if they have the permission, PV_CHANNEL_TEAM, in their user roles. This screen is provided by Oracle Partner Management, and this link is provided only if your implementation is integrated with Oracle Partner Management.

Memberships Page

Partner users can view the list of partner programs related to their companies, if they have the permission, PV_VIEW_MEMBERSHIPS, in their user roles. This link is provided only if your implementation is integrated with Oracle Partner Management.

Configuring Profile Menus

Oracle iStore's user framework allows you to configure the user Profile and user management menus to suit your business needs. This flexibility is useful for implementers who wish to control access to specific screens by specific user types and for users of different applications.

Access to functionality within each screen is controlled through roles associated with each user. Each permission within a user role is associated to a function which renders a portion of a menu. Roles are collections of privileges, and by creating custom roles and then limiting the permissions within these roles, administrators can control access to page elements. In addition, the menu rendering framework supports syntax which can restrict or allow users by users type (B2B or B2C).

At runtime, Oracle iStore's menu rendering framework filters out all functions to which the user has no access.

Supported Access Control Scenarios

Each function linked to the Profile menus can have specific levels of access control. Oracle iStore supports the access control scenarios shown in the following table. This table also shows the syntax to use for web HTML functions in the supported scenarios.

Web HTML Syntax for Profile Access Control Setups
Case Scenario Web HTML Syntax for Functions
1 No permission check a.jsp
2 No B2C users can access the page
Only some B2B users (with correct permissions) can access the page		 a.jsp?pcc=<permisson _code>&utc=b2b
3 All B2C users can access the page
B2B users (with correct permissions) can access the page		 a.jsp?pcc=<permisson_code>&utc=b2c
4 All users (regardless of B2C or B2B) with specific permissions can access the page a.jsp?pcc=<permisson_code>

Implementation Guidelines

Use the following guidelines to assist your setup:

  1. In order for the Oracle iStore menu rendering framework to know which permission and which user type is linked to each function, each function should append the permission code and user type to its web_html definition. See the above table for supported scenarios and syntax. For security reasons, when the Oracle iStore framework renders the menu, it hides the permission code in the UI.

  2. Profile menus are consistent across all sites, regardless of which responsibility is associated to the site. Therefore, if you configure the Profile menus, the configuration will affect all of your sites.

  3. You cannot entirely turn off a user's ability to see some Profile information. At a minimum, users will be able to see the My Profile menu within the Profile area.

  4. Common screens associated to common permissions (those with INT in their names) can be assigned to Oracle iStore, Oracle iSupport and Oracle Partner user roles.

  5. Profile screens that are application-specific should only be associated to permissions and roles owned by the integrating applications. For example, only Oracle iStore users who have been granted the business user role can access the company profile screens. Only Oracle iStore users that have been granted the primary user role can access the administration screens.

  6. All Profile pages are identified as secure pages.

Steps to Configure Profile Menus

You may use the following steps to configure the profile menus for different responsibilities. For complete information on Oracle Applications menus functionality, see the Oracle Applications System Administrator's Guide.

  1. Using Oracle Applications (FND) menus functionality, create a new profile menu tree.

  2. Link the profile menu to the user menu of the responsibility, IBE_CUSTOMER.

    For performance reasons, the profile menu root must be set up directly under the responsibility menu root, at the second level of the entire menu tree.

  3. Set the profile option, IBE: Use Profile Menu, at site level to the new profile root menu. This will override the seeded Oracle iStore profile menus attached to IBE_CUSTOMER responsibility.

Setting up Self-Service Login Assistance

If customers forget their user names or passwords, they can select the Forgot Your Username/Password information? link in the Login page to retrieve their login information. Oracle iStore Alert Workflow sends the seeded Forget Login e-mail notification to the user with his username and password.

Important: If your implementation is integrated with Oracle Single Sign-On (SSO), then the password assistance feature is provided through the SSO server. In this case, Oracle iStore's Forgot Password e-mail notification is not used. See the chapter, Integrating Oracle iStore with Oracle Single Sign-On, for more information.

Self-Service Login Assistance Process Flow

Following is the process flow for Self-Service Login Assistance:

  1. The user selects the Forgot your Username/Password information? link in the Login page. The Login and Password Assistance page opens.

    In this page, the customer can enter:

    • Username

    • E-mail address

    • Username and e-mail address

    Note that if Oracle iStore cannot find a unique match for either username or e-mail address, then the user must enter both values.

    If a user does not remember either username or e-mail addresses, he must contact the site administrator to reset the password.

  2. User submits the request.

    • If the user has entered username only, Oracle iStore validates the username in the database. If a record of the user name exists, the application resets the password and e-mails it to the customer using the seeded Forget Login notification message. If a record of the user name does not exist, an error message displays.

    • If the user has entered username and e-mail address, Oracle iStore validates the user name and e-mail address combination in the database. If a record with the combination exists, the application resets the password and e-mails it to the customer using the seeded Forget Login notification message. If a record with the combination does not exist, an error message displays.

    • If the user has entered an e-mail address only, Oracle iStore validates the e-mail address in the database. If only one record with the e-mail address exists, the application resets the password and e-mails it to the customer using the seeded Forget Login notification message. If no record with the e-mail address exists, an error message displays.

      If more than one record with the e-mail address exists, the application prompts the customer to enter a username. The application then validates the user name and e-mail address combination in the database. If the combination exists, the application resets the password and e-mails it to the customer. If the combination does not exist, an error message displays.

The following diagram shows the process flow that Oracle iStore follows to retrieve a user's login information.

Process Flow for Self-Service Login Assistance

the picture is described in the document text

See the chapter, Implementing Messages and Prompts, for details on how to access and modify the messages associated with this process.

Establishing Multicustomer Access Relationships

Here is an example for the setup steps used for creating additional contact and customer relationships. In this case, using Oracle iReceivables as a reference application to perform the data relationship setup.

Prerequisites: The IBE: Enable Multicustomer Access profile option must be enabled at the Site, Application or Responsibility level.

Assigning Existing Contacts to Additional Customers as a Self Service User

Use the following steps to assign existing contacts to additional customers as a self service user.

  1. Navigate to the Customer Maintenance page in Oracle Receivables.

  2. First, identify the customer which employs the existing contact. This contact would be designated as the From Customer Contact. In Customers tab, select Customer Type, enter search criteria and click Go. The search result is displayed.

  3. Select a customer. The Accounts section displays accounts available with the customer. Click Details for more information on an account.

  4. Select Communication tab. The Account Contacts list is displayed.

  5. Click Details of the account contact to be used. Note the details of the account contact identified as the From Customer Contact. You would now assign this contact to another customer.

  6. Navigate back to the Customers tab. Search for an existing customer, the To Customer, that would receive the new Self Service User relationship with the From Customer Contact.

  7. The available accounts for the To Customer are displayed below.

  8. Click Details icon for more information on an account for the To Customer. Select Communication tab.

  9. Click Create Contact. Enter the same contact details as the From Customer Contact.

  10. Click Apply. The Create Account Contact page appears.

  11. Click Use Existing Person. In the resulting Select Focus region, select the option which corresponds to the From Customer Contact.

  12. In the Account Contact page for the To Customer, click Add Another Role in the Contact Roles region. Select Self Service User from the Role menu.

  13. Click Apply.

  14. In the Account Detail page, click Apply to save the account and contact role relationship for the To Customer.

Verifying Data Setup for a Self Service Contact Relationship

Using Oracle Customers Online as a reference application, you can verify the data setup for a Self Service Contact Relationship:

  1. In the Customers tab, Organizations subtab, enter details of the To Customer defined earlier in the Simple Search region and click Go.

  2. Click To Customer link.

  3. The customer overview page appears. Click Visualize Relationships.

  4. The From Customer Contact now displays a Has Contact relationship with the To Customer.

When accessing the iStore application as a From Customer Contact B2B user, the Welcome Bin displays the default customer to which you have access. If you have been granted access to more than one customer, a magnifying glass icon is displayed in the Welcome Bin to switch customers and accounts, provided the IBE: Enable Multicustomer Access profile option has been set appropriately by the System Administrator.

Switching Customer and Account

Use the following procedure to switch the customer and account context for the current iStore application session:

  1. Log in to the iStore Customer application as a B2B user.

  2. The Product Catalog page appears. The Welcome Bin displays the default customer and account.

  3. If you have access to more than one customer, click the Search icon in the Welcome Bin. The Search and Select Customer page appears.

  4. Search and select a customer and account. The selected customer and account becomes the active customer and account for the current iStore application session. You can now place orders and view order history on behalf of this new customer account.

  5. On returning back to the Product Catalog page, the Welcome Bin displays your current customer and account context.

Note: The switch-to customers and accounts relationship is used only in the duration of your current iStore application session. When you log out and log in later into the iStore application, your default customer and account is used. The switch-to customers and accounts are not saved from the prior iStore application session.