Creating and Managing Profile Sharing Groups

About Profile Sharing Groups

A profile sharing group enables an account or an account's service to share a profile with other accounts or services. A profile stores ERAs or other types of information about an account.

The group owner can be an account or a service. If an account is the owner, profiles from all the services owned by the account are available for sharing. If a specific service is the owner, only profiles of that service are available for sharing.

Note:

Only service profiles can be shared. Account profiles cannot be shared, even if the profile sharing group is owned by an account.

You can use profile sharing to share an ERA, such as a friends and family list, with multiple accounts or services. For example, a friends and family list can be set up for a GSM service owned by one account and then shared so that a GSM service belonging to other accounts can use the same list.

You can also use profile sharing groups to share custom profiles you create.

You set up profile sharing groups in one of these ways:

Using Billing Care
Using Customer Center
Using a customized third-party client application calling BRM opcodes or the Billing Care REST API

For more information, see "Creating Profile Sharing Groups".

Note:

Profile sharing groups work similarly to charge and discount sharing groups, but profile sharing groups do not share balances and are not prioritized.

About Profile Sharing Group Membership

Only service profiles can be shared, but a profile sharing group's members can be accounts or services, as follows:

Account: If an account is a member, any eligible event generated by the account can use a shared profile.
Service type: When you specify a service type (for example, GSM) as a member, the events generated by all service instances within that service type are considered for shared profiles.

You can also specify that a member account that has not yet purchased a service of that type is automatically eligible for participation in profile sharing if it buys the service in the future.

Note:

The subtypes of the service type you specify do not become members. For example, if you specify the GSM service type as a member, specific GSM service instances such as GSM fax, GSM telephony, and so on do not.
Service instance: When you specify a service instance, such as a specific phone, as a member, only the events generated by that instance are eligible for the shared profiles. Specify membership using a specific service instance if you want to exclude other services of that type from profile sharing.

For example, if an account includes both work and personal phone services, a friends and family ERA might apply only to the personal phone.

Use the PCM_OP_SUBSCRIPTION_POL_AUTO_SUBSCRIBE_SERVICE opcode to customize adding a service to a sharing group. See "Adding Members to a Profile Sharing Group" in BRM Opcode Guide.

When setting up profile sharing groups:

Profile sharing group members must be equivalent to the owner. If the owner is a service, then the members must be the same service type. If the owner is an account, the members must also be accounts.
Members can have different charges or discount offers than the owners. To use of a shared profile, members need a charge or discount offer configured to use an ERA type or ERA label in the shared profile to give special charge pricing or discounts.
When the status of a profile sharing group's owner account is changed to inactive or closed, the shared profiles are no longer available to group members. During rating, the shared profiles are not retrieved. If an inactive owner account is activated, the shared profiles are once again available during rating.
By default, all members of a profile sharing group must reside in the same database schema. To enable profile sharing groups to include members from multiple schemas, see "Enabling Sharing Groups to Support Multiple Schemas".
By default, BRM does not validate profile sharing group members. You can customize the PCM_OP_SUBSCRIPTION_POL_PREP_MEMBERS policy opcode to add validation for profile sharing groups. See "Validating Profile Sharing Group Members " in BRM Opcode Guide.

Creating Profile Sharing Groups

To create a profile sharing group, you specify a group owner account or service, member accounts or services, and the list of the group owner's profiles that the members will share.

You create profile sharing groups as follows:

Using Billing Care
Using Customer Center
Using a third-party client application calling BRM opcodes or the Billing Care REST API

The following guidelines apply when creating a profile sharing group:

By default, all members of a profile sharing group must reside in the same database schema. To enable profile sharing groups to include members from multiple schemas, see "Enabling Sharing Groups to Support Multiple Schemas".
The owner cannot be a member of its own group.
The owner of a profile sharing group cannot also belong to a member-owned group. For example, if Account1 and Account2 both own profile sharing groups, and Account2 is a member of Account1's group, then Account1 cannot belong to Account2's group.
If you add a service type as a member rather than a specific service instance, all instances of that service type become members. However, the subtypes of the service type do not become members.

For example, if you specify the GSM service type as a member, all instances of GSM become members, but GSM fax, GSM telephony, and so on do not.

Adding a Profile Group to a Member's Ordered Balance Group

The /ordered_balgrp object stores the list of sharing groups to which an account or service belongs. This object is used with all types of sharing groups, but its significance varies:

For charge and discount sharing groups, /ordered_balgrp controls the order in which events impact the group's balances. See "How Charges and Discounts Are Applied".
For profile sharing groups, the order is not significant, so they are added to the end of the list in the PIN_FLD_ORDERED_BALGROUPS array.

When a profile sharing group is created or modified, the PCM_OP_SUBSCRIPTION_POL_AUTO_SUBSCRIBE_MEMBERS policy opcode automatically adds the group to the /ordered_balgrp object of each account or service that is a member.

Modifying Profile Sharing Groups

You can modify profile sharing groups using Billing Care or Customer Center, or by customizing a third-party application. You can change a profile sharing group in the following ways:

Add members to the group: When a member is added, shared profiles become available for events generated by that member.
Add shared profiles: When profiles are added to a profile sharing group, the profiles are automatically available to group members. The group owner must own the added profiles and have valid dates.
Delete members from the group: When a member is deleted, the group owner's profiles are no longer considered in rating or discounting the former member's events.
Delete shared profiles: A deleted shared profile is removed from the group's profiles list and is no longer available to members.
Change the owner of the profile sharing group: When the owner changes, members use the new owner's shared profiles instead of the old owner's shared profiles.

Deleting Profile Sharing Groups

You can delete a profile sharing group when the group owner's account is closed, or a CSR deletes the sharing group. When a profile sharing group is deleted, members can no longer use the profiles that the owner had shared.

When a profile sharing group is deleted, BRM also deletes the profile sharing group from each member's ordered balance group. For more information about ordered balance groups, see "Adding a Profile Group to a Member's Ordered Balance Group".

You delete profile sharing groups as follows:

Using Billing Care
Using Customer Center
Using a third-party client application calling BRM opcodes or the Billing Care REST API

Enabling Sharing Groups to Support Multiple Schemas

By default, all members of a sharing group must reside in the same database schema. If you want to include a member from a different schema, you must first use pin_amt to migrate the member to the same schema as all other sharing group members.

Alternatively, you can enable sharing groups to include members from other database schemas. To do so, use the pin_bus_params utility to modify the CrossSchemaSharingGroup business parameter in the system instance of the /config/business_params object.

To enable group members to reside in multiple schemas:

Use the following command to create an editable XML file from the system instance of the /config/business_params object:
```
pin_bus_params -r BusParamsSystem bus_params_system.xml
```
This command creates the XML file named bus_params_system.xml.out in your working directory. If you do not want this file in your working directory, specify the path as part of the file name.

Set CrossSchemaSharingGroup to enabled:

<CrossSchemaSharingGroup>enabled</CrossSchemaSharingGroup>

Save the file and change its name to bus_params_system.xml.
Use the following command to load this change into the /config/business_params object:
```
pin_bus_params bus_params_system.xml
```
You should run this command from the BRM_home/sys/data/config directory, which includes support files used by the utility. To run it from a different directory, see "pin_bus_params" in BRM Developer's Guide.
Read the object with the testnap utility or the Object Browser to verify that all fields are correct.

For general instructions on using testnap, see "Using the testnap Utility to Test BRM" in BRM Developer's Guide. For information on how to use Object Browser, see "Reading Objects" in BRM Developer's Guide.
Stop and restart the CM.

For more information, see "Starting and Stopping the BRM System" in BRM Developer's Guide.