Dynamics 365 for Professional Services

What CRM features do professional services firms need in Dynamics 365?

Professional services firms need CRM capabilities that go beyond standard sales pipelines. In D365 Sales, we configure opportunity management with custom stages reflecting the professional services sales cycle (lead qualification, proposal submitted, SOW negotiation, engagement won). We add custom entities for engagement tracking (project records linked to accounts and contacts with deliverables, milestones, and team assignments), resource management (consultant skills, availability, and utilization tracking), and financial tracking (budget vs actual, margin analysis). Power Apps canvas apps provide consultants with mobile time entry, expense logging, and client visit notes. Power BI connects to Dataverse to produce partner dashboards showing pipeline, utilization, revenue per consultant, and client satisfaction metrics.

How can Power Automate streamline professional services operations?

Professional services firms run on processes - proposals, approvals, onboarding, invoicing, and resource allocation. Power Automate handles all of these. Common automations we build: (1) Proposal workflow - consultant creates an opportunity in D365, flow generates a proposal document from a Word template, routes it for internal review, sends it to the client for e-signature via DocuSign/Adobe Sign, and updates the opportunity stage upon completion. (2) Engagement onboarding - when an opportunity closes as won, a flow creates the project record, assigns team members, creates a Teams channel for the engagement, schedules the kickoff meeting, and sends onboarding documents to the client. (3) Time and expense - weekly reminders to consultants who haven't logged time, automatic escalation to managers, and monthly invoice generation based on approved time entries.

How does Solzet configure resource management and utilization tracking in Dynamics 365?

Resource utilization is the single most important metric for professional services profitability. Solzet builds resource management directly into Dynamics 365 using custom Dataverse entities for consultant profiles (skills, certifications, availability, billable rate, preferred engagement types), project assignments (linked to opportunities and accounts with start/end dates, allocation percentage, and role), and time entries (daily or weekly logging with project, task, and billable/non-billable classification). Power BI dashboards connect to this data to show real-time utilization rates per consultant, per team, and per practice area - with drill-down into bench time, upcoming availability, and forecasted utilization based on pipeline probability. Managers use these dashboards to identify underutilized consultants and proactively match them to incoming opportunities. We also build Power Automate alerts that trigger when a consultant's utilization drops below a configurable threshold or when a project is approaching its allocated hours budget. This data-driven approach to resource management replaces the spreadsheet-based planning that most mid-market professional services firms still rely on - and consistently improves billable utilization by 10 to 15% in the first year after deployment.

Project Operations or D365 Sales and Dataverse: where does Solzet fit?

Dynamics 365 Project Operations is not one of Solzet's core services, and we would rather say so than stretch the claim. Our delivery is Dynamics 365 Customer Engagement, Dataverse and the Power Platform, and for most professional services firms that is where project tracking belongs: D365 Sales for the pipeline, custom Dataverse tables for engagements, resources and time, Power Apps for capture and Power BI for utilization and margin, often without the extra Project Operations licence. Where a firm has already licensed Project Operations, its lite deployment runs on Dataverse alongside D365 Sales, so we work on the parts that sit on our platform: the CRM side, the data model and security, Power Automate, plugins, PCF controls and the integrations to accounting. A typical engagement runs discovery and process mapping, environment and licence design, configuration, migration off spreadsheets or an older project tool, integration, user training and hypercare after go live, with one team from the first workshop to the last rather than a handover in the middle.

Project planning is the first thing we configure and the first thing partners look at. We build the project templates for the engagement types a firm actually sells, the work breakdown structure with tasks, effort estimates, dependencies and milestones behind each one, and the baseline that later shows where a project drifted from the plan. Estimates carry cost and revenue, so a project manager sees budget against actual as time is approved rather than at month end, and scope creep shows up as hours consumed by phase while there is still time to renegotiate. Where a project starts life as a quote, the plan is created from the opportunity instead of being retyped.

Resource management is where a services firm makes or loses its margin, so it gets its own workshop. We define resource roles and the skills and proficiency behind them, the cost rate and bill rate per role and per role with an effective date so historic projects keep their old rates, and the resource calendars, loaded with the Armenian public holiday calendar rather than the default that ships with a new environment. Generic resource requirements on the plan become named bookings through the schedule board, and the utilization picture behind it, billable against non billable, bench time and forecast availability, ends up in Power BI where partners read it. Getting the cost rate right matters more than it sounds: build it from real payroll cost including employer side contributions, or every margin figure downstream is optimistic.

Billing is configured around the contracts a firm signs, not the demo data. Time and materials, fixed price against milestones, retainers and mixed contracts each become project contracts and contract lines with their own billing rules, chargeability and approval path. Consultants capture time and expenses on the weekly cycle the firm already runs, approvals sit with the people who already sign them off, and approved amounts become the proforma. The statutory tax invoice stays where Armenian rules require it, in the local accounting package, so we integrate the two: approved billing data leaves the project system through Power Automate or a custom integration, and the issued invoice number and date come back onto the project contract, which is covered in more detail in the section on VAT and e-invoicing below.

None of this is worth much detached from the CRM, so the integration into Dynamics 365 Customer Engagement is part of the build rather than a later phase. One account and contact model serves sales and delivery, the D365 Sales quote flows into the project contract, delivery status is visible to the people selling the next engagement, and Power Automate carries the handover from closed won to project kickoff. Where standard configuration cannot express a pricing, approval or validation rule, our developers write C# plugins and custom API against the Dataverse event pipeline, and PCF controls in TypeScript and React where a standard control is not enough. Integrations to accounting, payroll, telephony and reporting run through the Dataverse Web API and custom connectors with retries and error handling somebody actually watches.

The regional delivery argument is straightforward. Yerevan is GMT+4, which leaves 4 to 6 hours of daily overlap with Western European hours and 6 to 8 with the UK, so a nearshore team shares your working day instead of handing work over overnight, and workshops, standups and training happen live rather than by email. Firms based in Armenia get the team in the same city, contracting and invoicing locally, in the same working day. The people on the project are senior certified engineers, holding PL-600, PL-400, PL-200 and the MB-210 and MB-230 module certifications, not a bench of juniors, and Armenian rates sit below Western European consultancy rates for the same certification and the same engineering standard. Work is delivered in English, Armenian or Russian, on B2B contracts with NDAs, GDPR compliant data processing agreements and IP ownership defined in the statement of work. The engagement models behind that, meaning a dedicated developer inside your team, a fixed scope project priced per milestone, managed support, or white label subcontracting for Microsoft partners, are set out on the Dynamics 365 developer and CRM consulting page linked in the guides below, and the management consultancy case study linked beside it shows an 80 consultant firm running joined up CRM, project tracking, time entry and utilization reporting in production.

Which Project Operations deployment shapes exist, and in what order does implementation run?

Dynamics 365 Project Operations is the Microsoft answer to project based selling, resourcing, time capture and billing, and it is the product most Armenian IT and consulting firms end up evaluating once spreadsheets stop scaling. The first decision is not a technical one. Project Operations ships in more than one deployment shape, and only the lite deployment runs entirely on Dataverse next to D365 Sales and stops at proforma invoicing. The heavier shapes pull in a separate Microsoft enterprise finance back end, which for a firm of 20 to 150 people in Yerevan is normally more platform than the business needs and more than local accounting practice can absorb, because the statutory ledger and the tax invoices stay in the Armenian accounting package regardless. Settle that question first: it decides licensing, timeline and how much of your finance process moves at all.

A realistic implementation sequence for an Armenian services firm runs in this order. (1) Write down the billing models you actually sell, meaning time and materials, fixed price against milestones, retainer and any mixed contract, and who signs each one off. (2) Model the client and pipeline side first in D365 Sales, because a project contract is fed by the quote and the opportunity, and a messy pipeline produces messy contracts. (3) Define the resource model: roles, cost rate and bill rate per role, and the resource calendars, using the Armenian public holiday calendar rather than the default one that ships with a new environment. (4) Configure project contracts, contract lines and billing rules so they match the models from step one instead of the demo data. (5) Roll out time and expense entry to consultants, which is the step that decides whether the whole programme succeeds, and put approvals on the weekly cycle the firm already runs rather than inventing a new one. (6) Connect billing to the accounting system, so approved amounts leave the project as data and issued invoice references come back. (7) Only then build the Power BI layer for utilization, margin and forecast, on top of numbers people already trust.

Two guardrails go with that sequence. The first is that the integration in step six belongs in scope from day one, not in a later phase, because the statutory ledger and the tax invoices stay in the Armenian accounting package whatever the project system does. The second is that the module is not always the answer. Where a firm concludes during scoping that a well configured D365 CE and Dataverse build already covers project tracking, resource management and margin visibility without the extra Project Operations licence, we say so and build that instead. That judgement is cheaper to make before the licences are signed than after.

How do Armenian VAT, e-invoicing and reporting change a Project Operations build?

Project Operations produces a proforma invoice, and in Armenia a proforma is not the document the tax authority recognises. A VAT registered Armenian company issues its tax invoice electronically through the State Revenue Committee system, and the statutory ledger usually lives in a local accounting package such as ArmSoft HS or 1C. That gives you a clean design rule: the project system owns what should be billed, the accounting system owns what was billed. Approved proforma lines flow out through Power Automate or a custom integration, and the issued invoice number and date flow back and sit on the project contract, so a partner reviewing an engagement sees real billing status without opening the accounting package. Local practice adds a step the generic guidance skips: services here are commonly accepted against a signed act of acceptance for the period, so tie the billing cycle to that act rather than to the calendar month alone, and keep the signed act attached to the record it belongs to.

VAT treatment splits your client base in a way no standard configuration will do for you. Work sold to an Armenian customer normally carries the standard rate of 20 percent, while consulting and IT services sold to a business customer outside Armenia commonly fall outside Armenian VAT because the place of supply follows the customer. A firm billing Yerevan clients and European clients from the same entity therefore needs the tax treatment held as data on the account and the project contract, derived from customer country and registration, not typed in by whoever raises the invoice. Confirm the treatment of your own contracts with your tax adviser, since it turns on the exact services and on how each customer is registered, and keep rates and thresholds as configuration rather than as code, because Armenian rules and the sector incentives for technology companies have moved more than once in recent years.

Three more local details decide whether the numbers come out usable. Currency: most Armenian IT and consulting firms contract in dollars or euros while reporting in drams at the Central Bank of Armenia rate, so keep AMD as the base currency, hold the contract currency on the project contract, and leave revaluation to the accounting system instead of reproducing it in Dataverse. Cost rates: build the consultant cost rate from real payroll cost including employer side contributions rather than from gross salary, or every margin figure in Power BI will be optimistic by a predictable margin. Calendars and language: load the Armenian public holidays into the resource templates, including the first week of January, or the utilization denominator is wrong for the whole first quarter, and give local users Armenian language forms and views where they read them, with client names stored in Armenian script and duplicate detection tuned for transliterated variants of the same company name.

Phased or big bang: which rollout fits an Armenian IT or consulting firm?

Generic guidance treats phased against big bang as an abstract programme decision. For an Armenian services firm it is usually settled by two local facts: the delivery team and the implementation team are the same billable people, and the finance function is often one or two people who also close the books. Both push towards phased.

The phased route suits most firms of 20 to 150 consultants and goes live in the order set out above: pipeline and client data, then contracts and the resource model, then time and expense, then the billing integration, then analytics. Each phase ends with something in production a partner can see, which keeps sponsorship alive through the months where nothing looks finished, and it lets you correct the resource model before hundreds of time entries are written against it. The cost is a longer elapsed timeline and a stretch where two systems each hold part of the truth, which needs one named owner and a written rule about which system wins.

A big bang cutover is defensible in a narrower set of cases: under roughly 40 people, one practice area, one or two billing models, no legacy project system that has to stay alive, and a hard external date such as a group reporting mandate. If you go that way, cut over on 1 January so the statutory year is not split across two systems mid stream, freeze scope at least six weeks out, and run the final fortnight in parallel with the old spreadsheets instead of switching them off on a Friday. Do not attempt it in your busiest delivery quarter, because the people who have to test it are the people billing the clients.

Either way the failure mode is the same, and it is not technical: time entry adoption stalls, the billing integration is left half built, and the reports never become the ones partners actually open. That is the point where a rollout quietly becomes a rescue. If a project rollout has already passed it, the useful next step is a forensic audit and a scope reset rather than more of the same, which is what the two rescue pages linked below set out, and the management consultancy case study linked beside them shows what the finished picture looks like once CRM, project tracking and utilization reporting are joined up.

What does Dynamics 365 project tracking look like for a consulting firm?

Project tracking for consulting firms in Dynamics 365 goes beyond simple task lists. Solzet configures a project management layer using custom Dataverse entities that link directly to the sales pipeline - when an opportunity closes as won, a Power Automate flow automatically creates the project record, populates it with scope details from the SOW, assigns the delivery team based on skills and availability, creates a dedicated Teams channel for the engagement, and triggers the client onboarding workflow. During delivery, project managers track progress through custom model-driven app views showing milestones, deliverables, risks, and dependencies. Time entries from consultants feed both utilization dashboards and budget-versus-actual financial views. Power BI reports give partners and practice leaders visibility into project margins, scope creep indicators (hours consumed versus budget by phase), and client satisfaction scores. At project close, a structured lessons-learned workflow captures what worked, what did not, and any reusable templates or components - building institutional knowledge that improves future delivery. This end-to-end tracking eliminates the gap between sales promises and delivery reality that plagues most consulting firms.

How should a firm running on Outlook and Word structure client and matter management?

Law firms, accountancies and advisory practices that run on mailboxes and shared folders rarely lose billable time and deadlines because people are careless. They lose them because the matter only exists as an email thread and a folder name, so nothing ties an hour, a document or a due date to the thing the client is paying for. The minimum structure that fixes it has five parts, and it is the same whether you buy a product or build one.

First, the client: one Account or Contact record per client, with duplicates resolved before anything is linked to it. Second, the matter: one record per engagement, file or case, linked to the client, with a responsible owner, a status that moves through defined stages (opened, active, on hold, closed) and the billing basis. Third, time captured against the matter at the moment of work rather than reconstructed on Friday from a calendar and sent items: an entry form reachable from the matter, from the email being answered and from a phone, with a daily nudge for anyone who has recorded nothing. Fourth, documents filed to the matter automatically rather than by individual discipline: the matter owns a document location, emails tracked from Outlook are linked to the matter, and Word documents are created from templates straight into the matter folder instead of a personal drive. Fifth, deadlines as records rather than calendar entries: each limitation date, filing date or client commitment is its own row with a due date, an owner and an escalation rule that reaches a supervisor before the date passes, not after.

Once those five exist, the questions partners actually ask become queries rather than a hunt through inboxes: which open matters have no time recorded this week, which deadlines fall in the next fortnight without an owner, which matters closed with unbilled time. In Dynamics 365 the Outlook side is handled by the Dynamics 365 App for Outlook and server-side synchronisation, and the document side by the SharePoint integration that gives each record its own folder; check current Microsoft documentation for how those behave in your tenant. Dynamics 365 Sales supplies the client, contact and business development side that the matter model hangs off.

Practice management product, Dynamics 365 or a custom CRM: which route fits your firm?

There are three honest routes, and the right one depends on how standard your matters are, what you already run and who has to use it.

A specialist legal or accounting practice management product is the right answer for many small and mid-sized law firms whose work follows the usual shape: matters, time recording, conflict checks, sector billing formats and, where the jurisdiction requires it, client or trust money accounting. Those products ship the sector conventions out of the box. The running cost is a per user subscription plus the cost of living inside its data model, and the limits show when the firm does work the product was not designed for, or needs matter data joined to a wider business development and marketing process. Solzet does not implement those products, and where one fits we will say so rather than build a copy of it.

Dynamics 365, configured for the matter shape, suits firms that already run Microsoft 365 and Teams, sell across several service lines, and need business development, client relationships and matter delivery on one record: consultancies, multidisciplinary advisory firms and larger practices that manage clients like B2B accounts. The build is the five part model above on Dynamics 365 Sales and Dataverse, with Power Apps for time capture and Power Automate for deadline escalation. The running cost is per user Microsoft licensing plus a partner or in-house administrator to keep it changing with the firm. Accounting, client money and the statutory ledger stay in the finance system, integrated rather than replaced.

A custom CRM on React, Node.js, PostgreSQL or .NET fits when the matter model is unusual (matters that split and merge, multi-party instructions, regulator-specific stages), when per user licensing across fee earners, support staff and occasional users does not add up, or when the firm wants to own the code, hosting and data outright. The running cost is hosting and a maintenance arrangement rather than licences, and the trade-off is that every sector feature is something you specify and fund rather than something that ships. Whichever route you choose, migrate the live matters and their open deadlines first and bring closed history across in a second pass.

What is the minimum data needed to see which projects are profitable?

A firm that cannot see which projects make money usually has plenty of data and no joins between it. Profitability needs five things, and buying a PSA product does not remove the need for any of them.

Time recorded against the project by everyone who works on it, at a level of detail the firm will actually keep up, usually project and phase rather than individual task. Cost rates held once, per role or per person with an effective date, built from real payroll cost rather than typed into each project or estimated by the project manager. Non-labour costs attributed to the project: subcontractors, travel, software and expenses coded to the project when they are approved, not spread across the practice at month end. Revenue recognised consistently, using the rule finance already applies, whether that is the invoiced amount, milestones or percentage of completion. And a project record that delivery and finance agree on: one identifier used in the time system, the CRM and the accounting system, with a named owner who opens and closes it.

The finance system stays the source for revenue and cost. The project layer calculates margin from time, rates and attributed costs and reconciles to the ledger every period; it never becomes a second set of books. When the two disagree, the fix is in the definitions, which is what our guide to dashboard numbers that do not match finance walks through.

How do you get a first trustworthy profitability number without a full PSA rollout?

The fastest path is narrow on purpose. Start with the projects that carry most of the revenue rather than the whole portfolio. Agree that project list and its identifiers with finance. Load cost rates once, from payroll. Make time entry against those projects mandatory for one full period, with a daily reminder and a weekly approval, and code non-labour costs to them as they are approved. At period end, calculate margin per project from approved time at cost rate plus attributed costs against the revenue finance has recognised, and reconcile the total to the ledger before anyone is shown a project-level figure.

On a Microsoft stack that is a small set of Dataverse tables for projects, rates, time and costs, a Power Apps time entry screen, Power Automate for reminders and approvals, and one Power BI report, linked to the client and opportunity records in Dynamics 365 Sales. It is deliberately less than a PSA: no resource scheduling, no billing engine, no project plans. Its job is to produce one number that partners and finance both trust, and to show which of the harder problems are actually worth solving.

The common failure is measuring projects nobody records time against. If internal work, pre-sales effort, quietly written-off overruns or a whole team never reach the time system, the report shows those projects as profitable because their largest cost is invisible. Check time coverage before margin: hours recorded per person against contracted hours, week by week. Until coverage is close to complete, a margin figure is a guess with decimals. And if the finance lead who holds the period-end adjustments is about to leave, write those adjustments down first, because the first trustworthy number depends on them.

Integrated PSA, extended Dynamics 365 or a custom build: which fits your firm size and project mix?

Once the first number is trusted, the platform decision gets easier, because you know which data problems were real.

An integrated PSA product, including Dynamics 365 Project Operations, fits firms with many concurrent projects, several billing models, shared resource pools that need scheduling across practices, and the appetite to change how people plan and record work. It is the heaviest route: more licences, a longer rollout, and time entry adoption that decides whether it works. Project Operations is not a Solzet core service; implementing Dynamics 365 Project Operations: key considerations sets out the decisions, and we work on the Dataverse, CRM and integration layer around it.

Extending Dynamics 365 with the project shape fits firms that already run D365 Sales or Microsoft 365, with a manageable number of project types and billing models, who need margin visibility and utilisation more than full resource scheduling. It is the model described on this page: project, rate, time and cost tables on Dataverse, integrated with the accounting system rather than replacing it, and it can grow into a PSA later without discarding the data.

A custom build fits firms whose project mix does not match any product (fixed-fee work split across entities, unusual cost allocation, projects that behave like long-running matters), or where per user licensing for every person who records time is the obstacle. The cost is ownership: you specify, fund and maintain every rule. On all three routes the finance system remains the source for revenue and cost, and the project layer reconciles to it rather than competing with it.