
For a 50-person US consulting practice, should approvals open more than 30 days live in Dataverse or a SharePoint list?
Use a Dataverse case record when your practice already runs an approved Dataverse environment with the right licences and an administrator who manages table permissions. Otherwise, a SharePoint list works as a case register, provided a named person owns the decision record and manual reconciliation is acceptable. In both designs, the approval case should live as its own record, and a separate, duplicate-safe flow should resume work once the decision lands.
A month-long approval is a business record, not a paused automation. Partners travel, scope changes, a client signs late. The question that matters isn't which tool can wait longest. The question is where the case lives so anyone can see it, and how downstream work restarts exactly once.
Deciding between the two options
- Dataverse case record plus separate event-driven processing fits when you already have a governed Dataverse environment, suitable licensing and an admin who owns table security; avoid it when you'd be standing up Dataverse just for this, or when you're assuming the standard Approvals connector by itself grants the table rights you need.
- A SharePoint or Microsoft Lists case register with short flows and a human-owned decision record fits a simpler process already running on SharePoint where someone can reconcile stragglers by hand; avoid it when you need a security and audit model equivalent to Dataverse, or when a custom status column would be mistaken for a native Approvals response.
Our recommendation for most 50-person consulting practices: pick the platform your firm already governs, because permissions and licences cost more to establish than either build. The one condition that flips the answer is existing Dataverse governance. With it, Dataverse wins on access control and event handling. Without it, a SharePoint register plus a disciplined owner is the leaner, more honest choice.

Why the case has to outlive the waiting step
Microsoft's Approvals connector documentation (page metadata dated 2024-03-01, updated 2025-08-25) describes the Create an approval action as one that "Starts an automated approval, but does not wait for the approval to complete. The approval is cancelable." A design built on that action naturally separates creating the request from acting on the answer, which is exactly the split a 30-day decision needs.
Dataverse offers a long-wait option too. Microsoft's Dataverse trigger article, last updated 2026-05-29, says the Dataverse Delay until property "never expires, allowing the flow run to wait for long periods of time." Read that narrowly. The statement covers that specific trigger property, not unlimited flow runtime, and not an approval that stays actionable forever. A persisted case record is still the safer anchor.
Resuming work exactly once
Duplicate runs are the quiet risk in event-driven resumption. The same Dataverse article states: "When multiple updates occur to a single row in a table, Power Automate evaluates the trigger for each update, even if the updated values are the same as the previous ones. These updates can result in multiple flow runs." A late edit, a reassignment or a reviewer saving twice can each fire your downstream flow.
Duplicate-effect protection belongs in the processing flow, not in hope. Store a case identifier at creation, record which downstream actions have already completed against that identifier, and have the resume flow check that marker before it creates an engagement, issues a purchase order or notifies a client. Trigger filters on the specific status column narrow the noise, but they don't replace the check.
SharePoint follows the same principle with different tools. Microsoft's SharePoint integration overview, last updated 2026-03-21, documents triggers on list item changes, list actions and reminder flows. A long-lived register built from those parts is our design interpretation, not a Microsoft-certified template, so the same identifier and completed-action marker should sit on each list item.
Overdue and superseded decisions need a human owner in both designs. A reminder flow can nudge an approver at day 14 and day 28, but somebody in operations has to decide when a stale request gets cancelled, reissued or recorded manually. The manual fallback is straightforward: the operations owner reviews the secure register, records the authorized decision with its evidence, and an administrator resumes the work.
Chrysis Networks designs and pilots this kind of case-register and resume pattern inside a firm's existing Microsoft 365 tenant, matched to whichever platform the firm already governs.
What to verify in a tenant pilot before rollout
- Who can read and write the approval response data and the case table or list.
- How each response correlates to exactly one case identifier.
- What happens when a response arrives late, twice, or after the request was superseded.
- Whether every user in the process has licence coverage for the connectors and tables involved.
Frequently asked
Does the built-in Approvals action wait 30 days for an answer?
Create an approval starts the request without waiting for it to complete, so the record of the case and the follow-up processing should live outside that step.
Can a Dataverse flow wait for a long time?
Microsoft says the Dataverse Delay until property never expires, but that applies to the property, not to unlimited runtime or indefinite approval validity.
Why did my resume flow run twice?
Power Automate evaluates the Dataverse row trigger for every update, even when values don't change, so repeated saves can produce multiple runs.
Is a SharePoint list good enough for a 50-person firm?
Yes, for a simpler process where an owner reconciles exceptions by hand, as long as nobody treats a list status as a native approval response or a full audit model.
Should we buy Dataverse just for long approvals?
Usually not; the governance, licensing and permission work outweighs the benefit unless the environment already exists.