You've got a web form on your site today. A case manager fills it out, a record gets created, and confirmation emails go to the person who submitted it, to an internal team, and maybe to the client. That's a lot of routing you don't think about, because your current form tool does it for you. The question that comes up when a services organization looks at Dynamics 365 Customer Voice is whether it can do all of that too, or whether you're taking on work you're currently getting for free.
Customer Voice is Microsoft's survey product, and it's built to feed Dynamics. That connection is real and it's the reason to consider it: a submission can create a contact and a service record, and the completed form links back to that record so anyone can see exactly how each question was answered. For a nonprofit administering coordinated services and community engagement across several teams, that link between the form and the record is the payoff. But it's worth being clear-eyed about what the tool is before you plan a migration around it.
Survey Tool First
Customer Voice looks and behaves a lot like Microsoft Forms with a Dynamics connection bolted on. You get sections, conditional logic to show or hide questions based on an earlier answer, field restrictions that force a valid email or phone format, rating scales, and satisfaction tracking. That last piece is genuinely useful: you can set an alert so a low rating gets assigned to a staff member to follow up, tracked to resolution inside the tool.
Where teams get surprised is the layout. You style a header, a logo, a theme color, and font sizes, and that's most of it. If your current form embeds paragraphs of explanatory text, plays a video while someone completes it, or pops up extra content when a certain option is picked, that kind of rich HTML control is not what this tool is built for. Ask that question up front, because the answer determines whether Customer Voice replaces your intake form or only your surveys.
Customer Voice is a survey tool. Power Pages is a self-service portal where an outside user logs into your Dynamics environment to submit an order or a ticket. They solve different problems, so name which one your use case is before you build.
The Automation Behind Every Form
Out of the box, a Customer Voice response goes to one place: the owner of the project. Everything past that, creating a record, copying the case manager on the confirmation, sending a different email to an internal department, sending yet another to the address entered on the form, runs on Power Automate. There is no scenario where these happen on their own. So the honest way to plan is this: every form you want to do real work needs a flow behind it.
That's not a knock on the tool. It's the design. But it changes how you budget the effort, because the work isn't building forms, it's building the routing. One reasonable pattern is a table-driven approach: a routing table that names each form and says what record to create and who gets notified, with a generic flow reading that table. The upfront build is heavier, but adding a new form later becomes adding a row rather than building a new flow and pulling in IT every time. The alternative is a custom flow per form, which is simpler to start and harder to live with.
The Product List Problem
Here's a limitation worth knowing before you design anything. Customer Voice can't pull a live product table into a dropdown. If you let someone request an item off a list of 15, you have to type all 15 options into the form by hand, and the option names have to match your product records for the automation to map them correctly. There's no equivalent of the add-another-line button some form tools give you.
The workaround is to design for a fixed maximum. Show the first item, then a yes/no question, and if it's yes, reveal a second item selection with the same 15 options repeated. Cap it at whatever your real-world maximum is, three items, or five, and if someone needs more, they submit a second form. So before you build, look at your own history: what's the most items a single request has ever included? That number sets the form.
Ownership and Who Loses the Form
One more thing that decides how you set this up. If a survey is owned by an individual and that person's account is disabled, when they leave, when a login is turned off, the survey goes with them. For anything running your intake, that's a risk you don't want. The fix is to own the forms under a service account rather than a person, so staff turnover never takes a live form down.
That choice has a consequence, and it's the same consequence as everything else here: a service account owns the form, so by default the service account receives every response, which means routing the notifications to the right people is, again, a Power Automate job. There's no version of this where one inbox is the right destination for every submission anyway. So the automation isn't an add-on. It's the part that makes Customer Voice usable as intake at all, and it's what should drive your decision on whether the tool fits before you plan the move off your current forms.
If you're weighing whether Customer Voice can replace the web forms your intake runs on, the answer turns on how much rich content your current forms carry and how much routing sits behind them, both of which are specific to your setup, so it's worth mapping those before you commit.