Organizations running Dynamics 365 Customer Service, Sales, and Field Service tend to treat external access as three separate problems: a case portal here, a quote-tracking idea there, maybe nothing for field service at all.
Power Pages licensing doesn't work per workload, it works per website. Authenticated users are counted once per website per month, no matter how many D365 workloads that website surfaces. A customer who checks a case status, tracks an order, and confirms a service appointment inside the same portal is one authenticated user, not three.
Three separate access mechanisms mean three logins, three sets of licensing math, three inconsistent experiences. One portal surfacing all three workloads means one licensed user pool covering all of it.
That's the part the ROI conversation usually misses. It's not just support cost per case, it's the licensing multiplier across every D365 workload a customer touches. A portal isn't a nice-to-have bolted onto one app, it's the economic foundation that makes a multi-app D365 investment behave like one coherent platform for the people outside your organization.
Where to go deeper: For the case-specific support-cost math, see Self-Service Portal in Customer Service: ROI & Savings Potential. For the full licensing breakdown behind the "per website" argument above, see Power Pages Costs & Licensing: The Complete Overview.
I map exactly this kind of consolidated access model in an Architecture Workshop, before a single portal page gets built.
