Participant Profile Best Practices
Overview
Participant Profiles are created for each step in the workflow. For each profile, you can define:
- Document Views: define whether actions and groups are shown or hidden, and whether attributes are read-only, editable, or hidden
- Transition Rules: define what workflow step will be next and set up email notifications
- User Access Rights: control who will be assigned to this profile once a transaction reaches this step (You can also control user access to a profile using the Advanced Forwarding Rules for the Step.)
Assigning Users to Participant Profiles
There are 2 ways to assign users to Participant Profiles:
User Access Rights
Here you can assign Participant Profiles based on:
- Company Type and User Type
-
Groups
Example: You could assign all FullAccessWithESales users to a profile called Administrator, and all members of the Manager group access to the Approver profile for all quotes.
The Participant Profile seen by the user is the first profile which evaluates to True. For this reason, you usually want to make an Admin Profile first.
Advanced Forwarding Rules
You can use the Advanced Forward Rules to assign Participant Profiles to Groups, based on attributes in the quote. Participant Profiles will only be assigned when the step changes.
Example: If approvers are assigned to quotes according to a user hierarchy, you can define a quote attribute to store the name of the approver group (for example, Manager-East, Manager-West, and so on). In the Forward Rule, you can use that attribute to determine which groups to assign to the Approver profile for that quote.
The Expected format of return value is: group~company~participantProfile [ |group~company~participantProfile ]*\
Participant Profiles are assigned according to Groups and User Types. You can't assign profiles to individual users by username.
Defining Document Views
Document views determine what is visible to users in the participant profile. Choices for the document views depend on the entity. For tabs, the options are Show or Hide. For attributes, the choices are Read/Write, Read-Only, and Hide.
You can adjust these setting from the attribute or action, enabling you to quickly adjust the behavior of the same entity across all steps.
If a tab is hidden, all attributes and actions within the tab are hidden.
Defining Transitions and Notifications
Notifications: Notification emails can be defined for each transition; each recipient must receive the same message. Recipients can be defined using the Participant Profiles for the current step and next step, or by defining an advanced function to specify the email address.
Transitions: Transitions rules are defined per action per profile. Several transitions may be defined for the same profile and action. The first transition to evaluate as true will take effect.
- Transition rules can have the same step as a destination. Use this to send notifications without changing steps. For example, use this to send a reminder email.
- Since notification emails must be defined for each transition, the same message may be defined in many places. By using XML templates and variables in the subject line as much as possible, you can reduce the number of places you will need to make changes to the messages.
XML notifications are sent to the partner server specified in Admin / Integration Settings. This allows integration with ERP and other non-CRM systems at specified transitions.
Always put an always true rule at the bottom of a set to avoid errors in logs.
Prevent Posting of Read-Only Fields
An internal property gives Oracle CPQ customers the option to prevent Commerce read-only fields from being posted back to the server after a Commerce action is invoked.
While enabling this property will have nominal impact on performance, it is recommended not to post information back to the server when the data will not have changed since it was last posted.
To enable this property, open a ticket on My Oracle Support.
Notes
Check performer steps, forwarding rules, and rights based on user type.
- Profiles are evaluated in the order in which they appear.
- When a user forwards a transaction manually from the transaction manager, the recipient will get the same access rights as the sender.
Related Topics
See Also
