This documentation applies to the 8.1 version of Service Request Management, which is in "End of Version Support." You will not be able to leave comments.

To view the latest version, select the version from the Product version menu.

Guidelines for designing services

Before you start creating services, take the time to design your services so that they serve your users well today and into the future. 

Design considerations

When you design your services, consider the overlapping goals of maintainability, usability, and performance. Work towards balancing these goals to develop a reliable and extendable system, and to ensure a trouble-free experience for your users.

Balancing goals and outcomes

GoalDesired outcomesDesign strategiesConsiderations
  • Ease of maintenance
  • Infrequent changes
  • Consolidate lesser-used services into one service request definition (SRD)
  • Reuse components that do not need to be changed frequently
  • Minimize the number of entitlement rules
  • In your organization, would it require less maintenance to combine some services into one SRD? For example, could you consolidate lesser-used services or services that do not change frequently?
  • If you need to update a shared component, how many SRDs would be affected?
  • How easily are new users incorporated into existing entitlement rules? Can SRDs be grouped (for example, by using packages) according to the entitlement rules that should apply?
  • Simplicity
  • Responsive UI
  • High system availability
  • Present fewer questions to the user
  • Leverage auto-fill functionality to populate question responses
  • Limit query menu results by using qualifications
  • Use stand-alone SRDs for heavily-used services
  • How much time and effort does it take for users to submit a request? Are they able to answer questions completely and correctly?
  • How many results are returned when the user clicks a query menu, and is the number of choices manageable?
  • To reduce possible down time, are there some SRDs that are very heavily used and should not be tied to shared components?
  • Responsive UI
  • Fast processing
  • Successful processing
  • Use fewer conditional questions, and fewer levels of conditional questions
  • Limit query menu results by using qualifications
  • Reduce the complexity of process definition templates (PDTs). For example, limit the use of conditions, nested PDTs, and parallel application object templates (AOTs), and only create variables that you plan to use.
  • Limit the number of Open Form actions in each SRD, and make sure that:
    • Data you look up for all actions is indexed correctly for your database
    • Qualifications return a manageable number of results
  • Are too many conditional questions being processed, which increases the time needed to update the screen?
  • For the number of results returned when the user clicks a query menu, does network latency become a factor?
  • Does the PDT contain too many unused variables, conditions, and nested PDTs, which impact performance?
  • Are there too many parallel AOTs in the PDT, which can cause the system to exceed the filter limit and halt processing?
  • Do too many Open Form actions execute? Do queries return too much data or is the data nonindexed, which can increase the amount of time needed to display or update the Provide Information window?

Design guidelines

BMC recommends that you use the following guidelines to align your services with the design goals and strategies presented in this topic:

Design guidelines

Functional areaGuidelines
SRDsCreate no more than 1000 SRDs.
QuestionsInclude no more than 100 questions in a single SRD, including conditional questions.
Conditional questionsCreate no more than 5 levels of conditional questions.
Query menusUse effective qualifications to limit results returned; otherwise, results are only limited by the AR System server limit.


Create fewer than:

  • 30 variables
  • 10 conditions
  • 6 nested PDTs
  • 20 parallel AOTs
  • Create one entitlement rule that includes everyone, and then apply exclusion rules for particular groups of SRDs or users.
  • Create SRD packages and configure entitlement rules for those packages.
  • Create no more than 3 Open Form actions.
  • Make sure that data you look up is indexed correctly for your database.
  • Create well-qualified queries to limit the number of records returned.

Related topic

Troubleshooting functional areas of the application

This version of the documentation is no longer supported. However, the documentation is available for your convenience. You will not be able to leave comments.