Power Automate and Power Platform Support Services for the Netherlands

Yes. We provide Power Automate and Power Platform support to Dutch businesses as a managed service, delivered remotely from Yerevan, Armenia. That covers break fix on cloud and desktop flows, proactive monitoring and alerting, connector and licensing reviews, DLP and environment governance, ALM, and new automation work alongside the support. Engagements run on a B2B contract in euros with a mutual NDA and a GDPR compliant data processing agreement. We work in your tenant, using access you grant and can revoke.

Armenia sits on UTC+4 all year, with no daylight saving. That makes us three hours ahead of Dutch winter time and two hours ahead of Dutch summer time, so our working day starts before yours and ends in your mid afternoon. On a standard schedule that is six hours of live overlap in winter and seven in summer, and we shift the team start time later where afternoon cover matters more. In practice it means a ticket raised at nine in the morning in Amsterdam is picked up inside a working day rather than waiting for one to open.

No, and we would rather say so on the page than have you find out on the call. Solzet is an Armenian company with no office in the Netherlands and no Dutch language helpdesk. What we offer instead is CET working hours, English as the working language, euro invoicing, a GDPR compliant contract, and senior Microsoft certified engineers at a rate a Dutch consultancy of the same seniority does not reach. If your requirement is on site presence in Utrecht or end user support in Dutch, a local partner is the right answer and we will say so.

Yes. This is a large part of what we do. Taking over an estate starts with an inventory of environments, solutions, flows, owners, and connections, because the usual reason a handover was never clean is that nobody had that list. We then move production off personal accounts and onto service accounts and connection references, triage what is broken by business impact, and document each supported process in a runbook. We do the same for stalled or abandoned Dynamics 365 Customer Engagement projects through our project rescue and takeover service.

It depends on the connectors. Standard connectors such as Outlook, SharePoint, Teams, and Approvals are covered by the Power Automate use rights seeded into Microsoft 365. Premium connectors, custom connectors, and the on premises data gateway require a separate licence, either attached to the users or to the process, and anything touching Dataverse or Dynamics 365 is on the premium side. Desktop flows and AI Builder are licensed separately again, with unattended RPA carrying its own requirement. Because Microsoft renames plans and adjusts what they include, we work from the current Power Platform licensing guide for anything that goes into a budget rather than from memory.

It means alerting built inside your own tenant on the flows that matter, reconciliation checks for the processes where a successful run does not prove the work was done, a named engineer reviewing the estate on a fixed cadence, and release wave changes tested before they reach your production environment. It does not mean a manned twenty four hour operations centre, and we do not describe it as one. If your automation genuinely needs cover through the night, that is a separate conversation about scope and cost, not a checkbox.

Build the alert into the flow, because the platform only emails the flow owner and that address is often a person who has left. Group the working actions into a Scope named Try, add the alerting actions after it, and open Configure run after on the first of them: untick is successful, and tick has failed, is skipped, and has timed out. Inside that path, result('Try') returns each action in the scope with its status and error body, so a Filter array over it gives you the failing action name and the connector's own message. Send that to a monitored shared mailbox with Send an email (V2) and to a Teams channel with Post message in a chat or channel, and include a link built from the workflow() function that opens the failed run directly. The step that is almost always missed is the last one: end the path with a Terminate action set to Failed, otherwise the run is recorded as Succeeded and your own alerting removes the failure from run history and from every report built on it.

Run history is retained for 28 days, which is shorter than most support conversations about a recurring fault. If you need a longer record, write it yourself: every Catch scope should insert a row into a Dataverse error log table holding the flow name, environment, run identifier, the record that triggered the run, the failing action, the status and error codes, the error message, a severity, and when it was resolved. That table gives you a model driven view, a count of how often each error repeats, and evidence that survives past the retention window. It also gives you something run history cannot: a place to record what was done about each failure.

Put three things around the billing flow. A failure branch using Configure run after, set to has failed, is skipped and has timed out, that emails a shared mailbox and posts to Teams and records the failure in a shared incident list. A canary flow that alerts when the billing flow has not completed successfully within its expected interval, which catches a flow that was turned off or stopped triggering. And a check that alerts when a run succeeds but processes zero records, or fewer than the source says it should have, because that is the silent failure a run status never shows.

Yes. Scopes, Configure run after, conditions and Terminate are built in, and Office 365 Outlook, Microsoft Teams and SharePoint are standard connectors, so a failure branch, a SharePoint incident list and a canary flow can all be built without premium licensing and without writing code beyond a few expressions such as result() and length(). Logging to a Dataverse table instead of a SharePoint list requires premium licensing in most cases, so check your licences before choosing it.

At minimum: a comparison of the count the source expected against the count the flow processed, a comparison of value totals, a check that the payment run happened and was acknowledged before its cut off, a uniqueness rule so a retry cannot create a duplicate invoice or payment, and a named owner for every mismatch until it is resolved before the period closes. These controls catch the failures where every run reports success.

No, and it is not meant to be. The CoE Starter Kit is an inventory and governance layer: it tells you which flows and apps exist, who owns them, which are orphaned, which connectors are in use, and with audit log ingestion enabled, which are actually used. It will not tell you at nine in the morning that last night's invoice run failed. That needs per flow alerting built into the flows themselves. The two are complementary, and the order we build them in is alerting first on the flows the business cannot run without, then the kit for the estate wide view. Two other things worth knowing before you install it: it is open source and supported by its community rather than by Microsoft support, and it needs a dedicated environment plus a properly licensed service account with Power Platform administrator rights, which is where most stalled installations stalled.

We work inside your Microsoft tenant, so your Dataverse and Power Platform data stays in the region you already chose for your environments and is not copied to Armenia as part of support. Access is through accounts you create in your own tenant with least privilege roles, which you can revoke at any time. Where we need to reproduce a problem outside production we use masked or synthetic data. Every engagement runs under a mutual NDA and a GDPR compliant data processing agreement, which Dutch readers will know as the AVG, with IP ownership defined in the statement of work.

We invoice in euros on a B2B contract and support international wire transfer, and we can also invoice in pounds or dollars where a group prefers it. For a Dutch VAT registered business buying services from a supplier outside the EU, the reverse charge normally applies, so we invoice without VAT and you account for it in your own return. Confirm the treatment with your own adviser, since it depends on your registration and how the services are classified.

No. Solzet works on the Customer Engagement side of Dynamics 365, meaning Sales, Customer Service, Field Service, and Customer Insights, plus the Power Platform: Power Apps, Power Automate, Power Pages, Dataverse, Copilot Studio, and PCF controls. We do not work with Business Central, Finance, or Supply Chain Management. If your automation needs to integrate with one of those, we build and support the integration from the Power Platform side and work with whoever owns the ERP.

A senior engineer can usually start within weeks rather than the months an internal hire takes, and an emergency stabilization can start sooner where something in production is down. For an ongoing allocation we recommend at least 20 hours a month, because below that the context retention costs more than the hours buy. Monitoring only engagements are smaller. We also take fixed price work for a defined piece of remediation where you want cost certainty before committing to a retainer.

Read the raw output rather than the summary, because two different problems share that status and that code. If the message names a privilege, such as missing prvCreateincident, the identity behind the connection does not hold that privilege at all and the fix is a security role change. If the message says SecLib::AccessCheckEx failed and carries an ObjectID, OwnerId, and AccessRights, the identity holds the privilege but not on that record, and the fix is privilege depth, record ownership, or team membership. The other thing to check immediately is which identity is actually running: with connection references it is whoever authorized the connection, which after a solution import is often the person who did the import rather than the person who built the flow.

It is a Dataverse service protection limit, counted per user across a rolling five minute window, and the response carries a Retry-After header in seconds that the connector will honour on its own. There are three of these limits with three codes: 0x80072322 for the request count, 0x80072326 for combined execution time, and 0x80072327 for more than 52 concurrent requests, and each one needs a different fix. The usual cause is a loop that reads a large result set and writes one row at a time, so the answer is batching, pagination with a deliberate threshold, lower concurrency on loops that write, and moving bulk work off the interactive window. Because the limit is per user, several flows sharing one service account share one budget, so the flow that fails is often not the flow that spent it.

An empty run history is a trigger problem, not a failure, because the history only lists runs that started. Check that the flow is on, then read the trigger condition and the Select columns list together: any column the condition references has to be in that list or it evaluates to null and the condition is false on every change. Check that the condition begins with @ and is written unwrapped, check the trigger scope, since a User scope trigger only fires on rows the flow owner owns and a handover changes the owner, and check the change type against what actually happens to the record. Only after that is it worth looking at the data itself. A flow that turns on cleanly but never runs is almost never a connection or licensing problem.