Dynamics 365 Customer Voice

I’d like to propose an improvement to the way Dynamics 365 handles active and inactive employees or positions, particularly in scenarios where date ranges are used as the primary determinant for status.

The Challenge:

Currently, the system relies heavily on date ranges to determine whether an employee or position is active or inactive. This approach has some limitations:

• When an employee leaves the company, all dimensional information tied to that employee is removed.
• This makes it impossible to retrieve and analyze historical data for past workers, which is crucial for reporting and trend analysis.

The Idea:

Rather than removing dimensional information for inactive employees, the system could:

1. Retain all historical records and simply flag employees or positions as inactive.
2. Ensure that historical data remains accessible for reporting and analysis purposes, even after an employee leaves.
3. Implement a more robust approach to managing statuses that accounts for the need to preserve data integrity over time.

This change would enable better historical tracking, improve data analysis, and avoid gaps in important business insights.

I believe this adjustment could significantly enhance the system's usability and value for organizations. Please let me know if you’d like to discuss this idea further.

When to Use Date Ranges for Data Retrieval

Date ranges are effective in data retrieval for specific purposes, but they should be applied thoughtfully to avoid unintended consequences.

When Date Ranges Are Useful

• Data Analysis and Reporting:
• Date ranges are excellent for filtering data to include or exclude specific timeframes in reports or analytics.
• Examples: Tracking performance within a fiscal year, analyzing trends over a period, or comparing metrics across months or years.

When Date Ranges Should Be Avoided

• Determining Active or Inactive Status:
• Using date ranges to set whether an entity (e.g., an employee or position) is active or inactive is not ideal.
• It can lead to the unintended removal or inaccessibility of historical data, especially for entities no longer active.
• Example: If an employee leaves a company, removing their information based on a date range prevents accessing their historical contributions for analysis.

Better Alternatives

• For status determination, use explicit flags (e.g., Active/Inactive) rather than relying solely on date ranges.
• Preserve all historical records and tie them to the entity, regardless of its current status, to ensure comprehensive data availability.

By distinguishing between these use cases, date ranges can be leveraged effectively without compromising data integrity or historical analysis.

If customer voice survey is send from DCRM using segment it does not update the respondent details.

Customer voice survey do not allow to hide response choice for the question in the survey

𝕋𝕠 𝕔𝕒𝕟𝕔𝕖𝕝 𝕒 𝕊𝕚𝕟𝕘𝕒𝕡𝕠𝕣𝕖, 𝕥𝕙𝕖 𝕣𝕖𝕢𝕦𝕚𝕣𝕖𝕕 𝕟𝕠𝕥𝕚𝕔𝕖 𝕡𝕖𝕣𝕚𝕠𝕕 𝕝𝕒𝕣𝕘𝕖𝕝𝕪 𝕕𝕖𝕡𝕖𝕟𝕕𝕤 𝕠𝕟 𝕥𝕙𝕖 𝕥𝕪𝕡𝕖 𝕠𝕗 𝕥𝕚𝕔𝕜𝕖𝕥 𝕡𝕦𝕣𝕔𝕙𝕒𝕤𝕖𝕕, 𝕥𝕙𝕖 𝕔𝕠𝕟𝕕𝕚𝕥𝕚𝕠𝕟𝕤 𝕥𝕚𝕖𝕕 𝕥𝕠 𝕥𝕙𝕒𝕥 , 𝕒𝕟𝕕 𝕥𝕙𝕖 𝕤𝕡𝕖𝕔𝕚𝕗𝕚𝕔 𝕗𝕒𝕣𝕖 𝕔𝕝𝕒𝕤𝕤 +𝟏-𝟴𝟱𝟱~𝟖𝟑𝟖~𝟜𝟡𝟠𝟚. 𝕋𝕙𝕖 𝕠𝕗𝕗𝕖𝕣𝕤 𝕒 𝕣𝕒𝕟𝕘𝕖 𝕠𝕗 𝕗𝕒𝕣𝕖 𝕠𝕡𝕥𝕚𝕠𝕟𝕤, 𝕖𝕒𝕔𝕙 𝕨𝕚𝕥𝕙 𝕧𝕒𝕣𝕪𝕚𝕟𝕘 𝕝𝕖𝕧𝕖𝕝𝕤 𝕠𝕗 𝕗𝕝𝕖𝕩𝕚𝕓𝕚𝕝𝕚𝕥𝕪 𝕨𝕙𝕖𝕟 𝕚𝕥 𝕔𝕠𝕞𝕖𝕤 𝕥𝕠 𝕔𝕒𝕟𝕔𝕖𝕝𝕝𝕒𝕥𝕚𝕠𝕟𝕤 𝕒𝕟𝕕 𝕔𝕙𝕒𝕟𝕘𝕖𝕤 𝕒𝕥 +𝟏-𝟴𝟱𝟱~𝟖𝟑𝟖~𝟜𝟡8𝟚. 𝕀𝕟 𝕘𝕖𝕟𝕖𝕣𝕒𝕝, 𝕥𝕙𝕖 𝕟𝕠𝕥𝕚𝕔𝕖 𝕡𝕖𝕣𝕚𝕠𝕕 𝕗𝕠𝕣 𝕔𝕒𝕟𝕔𝕖𝕝𝕚𝕟𝕘 𝕒 𝕊𝕚𝕟𝕘𝕒𝕡𝕠𝕣𝕖 𝕒𝕥 +𝟏-𝟴𝟱𝟱~𝟖𝟑𝟖~𝟜𝟡𝟠𝟚 𝕗𝕝𝕚𝕘𝕙𝕥 𝕚𝕤 𝕥𝕪𝕡𝕚𝕔𝕒𝕝𝕝𝕪 𝕒𝕥 𝕝𝕖𝕒𝕤𝕥 𝟚𝟜 𝕥𝕠 𝟜𝟠 𝕙𝕠𝕦𝕣𝕤 𝕓𝕖𝕗𝕠𝕣𝕖 𝕕𝕖𝕡𝕒𝕣𝕥𝕦𝕣𝕖, 𝕒𝕝𝕥𝕙𝕠𝕦𝕘𝕙 𝕥𝕙𝕖 𝕖𝕩𝕒𝕔𝕥 𝕣𝕖𝕢𝕦𝕚𝕣𝕖𝕞𝕖𝕟𝕥𝕤 𝕔𝕒𝕟 𝕧𝕒𝕣𝕪 𝕕𝕖𝕡𝕖𝕟𝕕𝕚𝕟𝕘 𝕠𝕟 𝕨𝕙𝕖𝕥𝕙𝕖𝕣 𝕥𝕙𝕖 𝕥𝕚𝕔𝕜𝕖𝕥 𝕚𝕤 𝕣𝕖𝕗𝕦𝕟𝕕𝕒𝕓𝕝𝕖 𝕠𝕣 𝕟𝕠𝕟-𝕣𝕖𝕗𝕦𝕟𝕕𝕒𝕓𝕝𝕖, 𝕥𝕙𝕖 𝕔𝕝𝕒𝕤𝕤 𝕠𝕗 𝕤𝕖𝕣𝕧𝕚𝕔𝕖 (𝔼𝕔𝕠𝕟𝕠𝕞𝕪, ℙ𝕣𝕖𝕞𝕚𝕦𝕞 𝔼𝕔𝕠𝕟𝕠𝕞𝕪, 𝔹𝕦𝕤𝕚𝕟𝕖𝕤𝕤, 𝕠𝕣 𝔽𝕚𝕣𝕤𝕥 ℂ𝕝𝕒𝕤𝕤), 𝕒𝕟𝕕 𝕥𝕙𝕖 𝕤𝕡𝕖𝕔𝕚𝕗𝕚𝕔 𝕥𝕖𝕣𝕞𝕤 𝕠𝕗 𝕥𝕙𝕖 𝕗𝕒𝕣𝕖 𝕒𝕥 +𝟏-𝟴𝟱𝟱~𝟖𝟑𝟖~𝟜𝟡𝟠𝟚.

Currently, a user can create up to 400 surveys across all projects. Unfortunately, there is no option to extend this limit, requiring users to delete old surveys to make room for new ones. This approach is not user-friendly, especially when users need to retain all surveys for business purposes.

It would be very helpful if adjustments could be made within the Customer Voice app.

For example, adding a (custom) Dataverse table to the app navigation bar.

A suitable use case would be to add the “Task” dataverse table for directly creating tasks without switching apps.

To enhance user experience and improve the efficiency of the interaction process, we propose expanding the message triggers within the system. Specifically, we suggest adding notifications for the following events:

Pre-Connection Notification: Notify the user when a conversation window is opened before an agent has joined the chat. This helps manage user expectations and prepares them for a wait.

Bot Start: Send a notification when a bot starts interacting with the user, allowing users to understand that they are communicating with automated assistance.

Bot End: Notify users when a bot finishes its interaction and the conversation is transitioning, giving them clarity on the next steps.

Bot-to-Agent Handoff: When a bot hands off the conversation to a human agent, a notification should inform the user that a human agent is now taking over, ensuring smooth continuity in the interaction.

By expanding the notification triggers to cover these events, we can ensure better communication and transparency between users and the system, ultimately improving user satisfaction and reducing friction during interactions.

There are 2 fields in Dataverse table Survey Invite, "From" or "From email address". When we send survey invite to the customers. Survey Invite records get created but these two fields are empty always. There is no way to track from which email address or user the survey invite was sent.

This will be great if we can capture this as well.

As a Data Management/Data Governance Leader, I want to provide predefined lists of choices for dropdowns, choice selections etc to ensure the data collected is coherent with our enterprise reference data. The organisation requires adherence to a range of standards, and providing read-made and centralised option lists would provide an easier end-user experience and provide confidence within the organisation's data and security functions.

We are currently facing an issue with our Customer Voice Surveys. Our goal is to link customer survey responses to specific conversations without using a pre-survey question in the chatbot which is not applicable. So as a workaround, I created a Power Automate flow that triggers when a Customer Voice survey is submitted. The flow updates the created record with personalized customer data, allowing us to capture the customer information. However, the survey title remains anonymous! even after updating the respondent email address, which is not ideal. Additionally, there is a problem where multiple surveys in the same session are being linked to the same conversation, even though they originate from different conversations and different customers.