Creating on-behalf-of definition rules
The application administrator can create on-behalf-of (OBO) definition rules to specify the following actions:
- A member of a support group can enter a service request on behalf of another individual in a company, an individual in a specified company, or an individual in a specified group. The Global company can be used to allow entering a service request for anyone.
- An individual can enter a service request on behalf of another individual, another individual in a specific company, or an individual in a specified group.
Anyone can enter a service request on behalf of anyone else by using a company-to-company rule with Global for the requester and Global for the requester to act on behalf of another individual.
Users acting on behalf of another user can view only requests that they submitted on behalf of that person, and not requests submitted by the user or requests submitted by others on behalf of the user.
You can use this feature even if you choose to disable entitlement management. For more information about how this feature works, see How on-behalf-of functionality works.
Recommendation
BMC recommends that you create OBO rules that allow service desk staff to create service requests on behalf of any user.
Note
All new service requests are validated against On Behalf Of (OBO) rules, except those created automatically by BMC fulfillment applications. For example, when a web service creates a service request, an OBO rule must be configured so that the Requested By user can submit a service request on behalf of the Requested For user.
For more information, see Integration methods and Request_Submit_Service.
To create an OBO definition rule
- From the Application Administration Console, click the Custom Configuration tab.
- From the Application Settings list, select Service Request Management > Entitlement > On Behalf Of Management, and click Open.
- From the On Behalf Of Definition Rules form, click Create.
- Enter a unique name for the definition rule.
- Select a company.
- Select a status.
Define the requester by selecting a Requester Type.
Requester Type
Steps to follow
User
- Click Select User.
- In the People Search form, enter criteria to find a particular person from the People form, and click Search.
- Select a person from the results list, and click Select.
- The login ID of the person appears.
Note: You can select any user from any of the companies to which you have access.
Company
Select information from the remaining fields (for example, Organization, Department, and so on).
Group
Select a group name for the company (for example, Calbro Services > Service Desk). When selecting a group for the Requester Type, you can only select a group to which you have access.
Define a user or company that the user is acting on behalf of.
If you select this Requested For Type
Follow these steps
User
- In the People Search form, enter criteria to find a particular person from the People form, and click Search.
- Select a person from the results list, and click Select.
- The login ID of the person appears.
Company
Select information from the remaining fields (for example, Organization, Department, and so on).
Group
Select a group name for the company. When selecting a group for the Requester Type, you can only select a group to which you have access.
- Click Save.
- (Optional) If you create a rule that allows a person to submit a service request (or work order) on behalf of someone else, check that the Organization and Department fields of the People records belonging to the people for whom requests can be made contain the correct entries for those people.
If those fields do not contain the correct values (or are empty), those people are not available in the list of people for whom the requester can make requests.
Comments
My company has been struggling with trying to find a way to allow members of an entitlement group (we'll call it "Group X") to submit service requests on behalf of all users in the company. This is a problem because all the services the user needs are located under the entitlement Group X, which by design, excludes all users unless they are members of Group X. We do not want to expose these services to the general population, by design, we want only those in Group X to view and submit these service requests.
Hi Romer,
Thanks for your comment, and sorry it has taken so long to get back to you.
If you haven't already done so, consider posting your inquiry in BMC Communities. It might generate some discussion and ideas from the members there.
Cathy
Hi all,
I haven't found any literature about the workflow that first checks if a user that's submitting a request has already made it previously for the same user. I mean the FL guide called "OBO:ConsoleSearchOBOUserGuide" (that contains the filters "OBO:ConsoleBuildOBOPastUserQual1" and "OBO:ConsoleBuildOBOPastUserQual2"). I've observed it could be useful when you have few users that use the OBO functionality but it becomes a burden when it comes to users that act as "submitter" for a large pool of people. Would it be safe to disable them? Does it impact any other area of the OBO functionality?
Regards,
Vanessa
Hi Vanessa,
Thanks for your comment. If you haven't already done so, consider posting your question in BMC Communities to reach more members of the user community.
Depending on what you find, you can create an "idea," like this example. Customer Support can also enter a request for a product enhancement on your behalf. To contact Customer Support with your feedback, click here.
Regards,
Cathy
Log in or register to comment.