Carlos Martinez Casas

The current method of managing work hours for resources in Field Service requires setting individual calendar rules for each day or defining a fixed end date for recurring patterns. While functional, this approach can lead to inefficiencies when handling large datasets, as seen in scenarios with thousands of calendar rules.

A customer managing an interpreter pool resource encountered significant performance degradation caused by over 7,000 calendar rules. This not only led to timeouts when modifying child resources but also required manual intervention to delete historical data spanning thousands of years.

To resolve the issue, the customer implemented a 24-month limit on work hours and committed to periodic updates. However, they identified an opportunity to enhance the system’s functionality by automating the extension of recurring patterns.

Introduce a feature that allows administrators to:

1. Set a recurring work hour template for resources without requiring an explicit end date.
2. Automatically extend the recurring pattern by a user-defined interval (e.g., one month) once the current pattern is a specified duration from expiration (e.g., 12 months out).

Suggested Implementation Details:

• Introduce a configuration option in the work hours setup to enable auto-extension.
• Allow administrators to specify the extension interval (e.g., monthly, quarterly, annually).
• Provide notifications or logs to inform users when the system extends work hours.

This would prevent the accumulation of excessive calendar rules, improving system responsiveness when modifying resources and reduces the need for manual updates to work hour templates.

The current lack of documentation regarding the specific storage entities for Customer Insights - Journeys interaction data has presented significant challenges for customers. The desired outcome is to have a clear and accessible way to identify and retrieve interaction data beyond platform-imposed limits

Current Limitations:

• Interaction data entities are not documented, leaving users uncertain about data location and schema.
• The integration with Microsoft Fabric is beneficial but requires additional setup, technical expertise, and often licenses that may not align with customer budgets.
• No direct API is available to retrieve all interactions programmatically.

Proposed Enhancements:

1. Comprehensive Documentation: Clearly identify and document the entities and data structure for Customer Journeys interactions, whether stored in Fabric, Azure, or other services.
2. Direct Data Access Options: Introduce an API or expand capabilities in the existing platform to allow customers to retrieve interaction data programmatically without dependency on third-party tools.
3. Simplified Export Tools: Increase export limits or provide built-in options for larger datasets directly from the platform.

Addressing these points will empower customers with better data accessibility, reduce reliance on third-party solutions, and enhance the overall utility of Customer Insights - Journeys.