Dear Freshservice Product and Engineering Teams,
We are writing to propose a fundamental architectural enhancement to the Freshservice platform: the ability to associate key configurations (Workflows, Form Rules, SLAs, Fields) directly with individual Service Catalog Items.
The Current Challenge: A Centralized, Condition-Based Configuration Model
Currently, critical business logic components are managed in centralized, globally-scoped admin sections. To apply logic to a specific Service Item, we must create rules with explicit conditions, such as IF "Requested Item" is "New Laptop Request" THEN....
While functional, this model presents significant challenges as an organization scales:
-
High Maintenance Overhead: To understand or modify the end-to-end behavior of a single Service Item, an administrator must navigate to 4-5 different sections (Workflow Automator, Business Rules for Forms, SLA Policies, Field Manager). This fragmentation makes management complex and time-consuming.
-
Increased Risk of Errors: A single large list of workflows or rules for all items is inherently error-prone. A minor mistake in a condition can have unintended consequences, impacting unrelated services.
-
Lack of Scalability: As the service catalog grows, the list of automations becomes an unwieldy chain of IF/ELSEIF conditions, making it difficult to manage, debug, and audit.
-
Poor Encapsulation and Portability: A Service Item is not a self-contained entity. Its logic is scattered across the platform, making it impossible to easily clone, export, or manage a service and its complete set of rules as a single unit.
The Proposed Solution: An Item-Centric, Context-Based Configuration Model
We propose a shift towards a model where business logic is encapsulated within the Service Catalog Item it governs.
Instead of managing global lists, administrators should be able to configure rules and policies from within the Service Item's settings page. This would mean having dedicated tabs for "Workflows," "Form Rules," and "SLA Policies" directly on the item's configuration screen.
Under this model:
-
Any workflow created under the "New Laptop Request" item would only trigger for that item. The IF condition becomes implicit and unnecessary.
-
The form rules would only apply to that item's form.
-
The SLA would be inherently linked to that service.
Key Configurations to be Scoped:
-
Workflow Automator: Workflows should be creatable at the Service Item level.
-
Business Rules for Forms: Form logic should be defined within the item's form editor.
-
SLA Policies: An item should have its own specific SLA assignment, overriding workspace-level policies.
-
Field Manager: The association of which fields appear on a form should be managed exclusively within the item's form designer, creating a clear boundary.
Benefits of this Architectural Shift:
-
Reduced Total Cost of Ownership (TCO): Drastically simplifies administration and reduces the time spent on maintenance and debugging.
-
Enhanced Reliability: Isolates the logic for each service, eliminating the risk of cross-item interference.
-
True Modularity and Scalability: Enables the creation of self-contained, reusable Service Items that can be managed, cloned, or migrated with their entire logic intact.
-
Increased Administrator Agility: Empowers service owners to manage their items without needing to navigate complex, global rule sets.
This evolution from a centralized to a distributed, object-oriented configuration model would represent a significant leap in platform maturity, aligning Freshservice with modern DevOps and "Configuration as Code" principles. We believe this would be a game-changer for enterprise customers managing complex service catalogs.
We are eager to discuss this proposal further and understand if it aligns with your long-term product vision.
Thank you for your consideration.
