Phased rollout


This documentation supports the 21.05 version of BMC Service Request Management. To view an earlier version, select the version from the Product version menu.

Guidelines for designing services

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.

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 non-indexed, which can increase the amount of time needed to display or update the Provide Information window?

Design best practices

We recommend that you use the following best practices to align your services with the design goals and strategies:

Functional areaBest practices
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.
Was this page helpful? Yes No Submitting... Thank you