Create a custom app or a catalog item?

[CMa_yfield]

For simple request workflows, service catalog items are quick to implement and easy to modify. However, there are some technical nuances that might necessitate the need for a custom scoped application (using App Engine Studio) where your workflow request table is a custom table, to get the business value you are looking for.

Note: This article applies to custom scoped apps with a custom primary request table vs. using the OOB catalog tables (REQ or RITM), regardless of whether or not these OOB catalog tables are used for a catalog item in either global or a custom application.

Ask yourself the following questions.

For any that have an answer of ‘yes’, a custom scoped application might be a better fit than a solution using the OOB catalog tables (REQ or RITM).

Data and Reporting Considerations

• Do you need to run regular reporting against the data within the request?
• WHY? Catalog variable data reporting is less user-friendly than custom app data reporting. Custom tables provide better executive-level reporting capabilities with normalized data structures.

• Does your request have repeated rows of data that would be children to the parent request? For example, if your request is for an expense report, it may require child records, one each for itemized detail line within the expense report. These itemized records would be considered children to the parent expense report request record.
• WHY? Catalog MRVS (Multi-row variable set) data reporting is less user-friendly than custom app data reporting. Custom applications handle parent-child relationships more efficiently.

Security and Access Control

• Does the data require strict or dynamic security? (e.g., if you are the 'requester' in a request, you can view your own record, but no others)
• WHY? While you can create security ACLs on request items, too many of these will negatively impact the performance of your platform. Application-specific roles and permissions are better handled in scoped applications.

Data Management and Reusability

• Do data points (fields) for your workflow have drop-down values for selection in your request that need to be actively managed? (Will this list of options change often and/or do you want to be able to update it without involving a developer?)
• WHY? Normalizing the data as reference tables as opposed to choice fields that are replicated across the platform gives you roll-up and break-down capabilities for executive level reporting.

• Will the data points within your request be used by other requests, workflows or applications in the platform?
• WHY? Normalizing the data as reference tables as opposed to choice fields that are replicated across the platform gives you roll-up and break-down capabilities for executive level reporting. However, consider that if the catalog item is intended to be reused across multiple applications, it might be more appropriate to build it in the Global scope.

Workflow Complexity and Maintenance

• Will the data points within your request be updated by different people at different times within the workflow of the request?
• WHY? Catalog variable data editing and audit review is much more complicated to customize for implementation than OOB custom app data reporting which has these features by default.

• Does the data within your request, after initial submission by the end user, require extensive calculations or business logic to be applied as it goes through its workflow?
• WHY? Too many business rules on the shared service catalog REQ and/or RITM tables will have a negative impact on performance for your catalog item.

• Does your workflow have many branches in its logic?
• WHY? Complex/multiple flows on the shared service catalog REQ and/or RITM tables will have a negative impact on performance for your catalog item.