- Custom API (modern, contract-based)
- Classic Action (legacy process-based “Action”)
This article compares them in plain language, with real scenarios and governance considerations (security, auditability, and maintainability). It’s designed for solution architects, functional consultants, and makers who need to make the right platform choice, not just “get it working.”
1) Quick definitions (what each is)
Classic Action (Process-based Action)
A Classic Action is built using the legacy process designer. It represents an operation that can be called from certain places (flows, code, or other processes). It can execute “workflow-style” steps and can also have plugins registered on its message.
Key idea: It is process-oriented and historically aligned with the old workflow engine.
Custom API
A Custom API is a first-class Dataverse concept for defining a business operation with:
- request parameters (inputs)
- response parameters (outputs)
- bound or unbound execution (tied to a row, or not)
- optional main handler (“Plugin Type”) and/or additional processing steps
- security gating (who can execute this operation)
Key idea: It is contract-oriented and designed for modern ALM and governance.
2) A simple architecture view (how they “feel” in a solution)
Think of the two approaches like this:
Classic Action (legacy process mindset)
User/Flow/Integration
→ Action (Process steps / legacy orchestration)
→ Optional plugin hooks
→ Updates / creates records
Custom API (modern operation contract)
User/Flow/Integration
→ Custom API (explicit inputs/outputs + security gate)
→ Main operation logic (typically plugin)
→ Optional additional steps (if allowed)
→ Updates / creates records + audit events
If you’re building “audit-ready” regulated workflows, Custom API typically gives you a cleaner foundation for standardized, repeatable operations.
3) Governance comparison (what matters in regulated / security-sensitive systems)
| Dimension | Custom API | Classic Action |
|---|---|---|
| Operation contract | Strong, explicit request/response parameters. Easier to standardize across environments. | Possible, but tends to be “process-first” and can become inconsistent across solutions over time. |
| Security / governance | You can treat “execute operation” as a first-class privilege concept (plus normal table privileges). | Usually relies more on process access and underlying table privileges; can be harder to govern at scale. |
| Audit traceability | Excellent for “who did what, why, and with what inputs,” because the operation is explicit and centralized. | Can work, but often becomes scattered across process steps and variations, especially as complexity grows. |
| Maintainability | Designed for modern ALM; tends to age well when logic grows or requirements change. | Works, but legacy workflow/process sprawl is common in long-lived environments. |
| Best fit | Critical operations: Approve/Reject/Close; regulated decisions; shared operations used by UI + flows + integrations. | Legacy compatibility, small/simple orchestration, environments already heavily invested in classic processes. |
4) Real scenario: “Critical status transitions” (Approve / Reject / Close)
This is where the difference becomes obvious. In regulated workflows, you typically need:
- Consistent validation (only allowed transitions)
- Least privilege (not everyone who can edit a record can approve it)
- Strong audit trail (who approved, why, what data supported the decision)
- Bypass prevention (no direct field updates to “Approved”)
Recommended pattern (governance-first): “Controlled transition + Guard”
Step A: Use a Custom API for critical transitions
- Operation: TransitionStatus (Approve/Reject/Close)
- Inputs: Transition type, reason, optional approval reference, source channel
- Outputs: new status, audit event id
Step B: Add a Guard to prevent bypass
To enforce governance, block direct updates into critical statuses. The concept is:
If someone tries to set Status = Approved/Closed directly
→ Block it
Unless it came from the approved operation (Custom API)
→ Allow it
Why this matters: It turns “policy” into “enforced behavior,” not just training or documentation.
5) How this supports “audit-ready” requirements (traceability)
Audit questions are predictable. If your operation is centralized (Custom API), you can capture evidence systematically at the moment a decision is made:
- Trigger/source: UI button, Flow name, integration endpoint
- Actor: who initiated it (user / app user)
- Approver: if approval is involved
- Reason: required justification text
- Data used: a snapshot of key fields and prerequisites at decision time
- Outcome: status transition and timestamps
This makes it much easier to answer questions like:
- “Why was this record approved?”
- “Which data points supported that decision?”
- “Who approved it and when?”
- “Were there any approvals missing required documents?”
6) When Classic Action is still reasonable
Classic Actions can still be appropriate when:
- Your environment already relies heavily on legacy processes and re-platforming isn’t justified yet.
- The operation is simple and does not require strict bypass prevention.
- You’re doing lightweight orchestration that is unlikely to grow.
However, for long-lived systems, it’s common to see “process sprawl” (many similar processes with inconsistent rules). That’s where Custom API tends to win over time.
7) Practical decision checklist (maker-friendly)
Use Custom API when you answer “yes” to most of these:
- Will this operation be used by multiple channels (UI, flows, integrations)?
- Do you need a single authoritative implementation of business rules?
- Do you need strong traceability and consistent audit evidence?
- Should only certain roles be allowed to execute this operation?
- Will this logic likely evolve over time?
Use Classic Action when:
- The operation is small, stable, and legacy-oriented.
- You’re working inside a solution pattern that already depends on classic processes.
8) Recommendation (what I would do for regulated operations)
If you’re building a system where privacy, access control, auditability, and governance are first-class requirements, a practical approach is:
- Use Custom API for critical, high-risk operations (Approve/Reject/Close, write-offs, official submissions).
- Use a guard approach to prevent bypass (no direct updates into critical statuses).
- Capture standardized audit events at operation time (reason, source, approver, key data snapshot).
This consistently produces solutions that are easier to govern, easier to audit, and more resilient as teams and processes change.
Closing
Custom API is not “just a newer Action.” It’s an operation contract that fits modern governance: repeatable, enforceable, and auditable. If your solution must stand up to compliance scrutiny, Custom API should be your default starting point.
If you found this useful, consider creating a standardized “operation catalog” in your solution: a small set of Custom APIs for critical business decisions, each with clear inputs, outputs, and audit evidence requirements.
No comments:
Post a Comment