Guidelines for designing services

• 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?

PDTs

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.