Slack and Teams Can Carry the Approval — Not the Full Seat

Full platform seats get assigned for reasons that have nothing to do with core platform work: someone needs to approve a record, get notified when a status changes, or respond to a request without ever opening a list view, a report, or a record page beyond the approval action itself.

• Approval-only users — assigned a full seat to click approve/reject on a discount, a PTO request, or a change ticket.
• Notification-only users — logged in only to see that a case, opportunity, or incident moved to a new stage.
• Limited-access requesters — submit a leave request, an access request, or a purchase request and never touch the underlying object model again.

Our User Utilization AI agent flags these patterns from actual login and interaction data — not job titles — before anything is proposed.

Not every workflow belongs in a chat interface. We separate candidates by interaction pattern, not by department or seniority.

• Good fit: single-step approvals, status notifications, simple intake forms, yes/no/escalate decisions, read-only record summaries.
• Poor fit: multi-object edits, anything requiring list views or reports, complex configuration, or work that depends on platform-native validation rules and page layouts.

The Discovery and Architecture AI agents map each candidate workflow against this split before any license change is scoped, so the recommendation is workflow-specific rather than a blanket move-everyone-to-Slack policy.

The interaction moves; the record does not. A Slack workflow step or a Teams adaptive card triggers an action that writes back to the core platform through its own API or approval framework — the same write path a logged-in user would have used.

• Architecture agent designs the interaction pattern (Slack workflow builder step, Teams adaptive card, or bot-driven approval message) against the target platform's approval and notification framework.
• Integration agent wires the write-back path — API call, approval action, or webhook — so the core system executes and records the decision exactly as it would from its native UI.
• Workflow agent rebuilds the underlying business process so the approval step routes correctly regardless of which surface the approver uses.
• Testing agent verifies that decisions made in Slack or Teams produce identical downstream results to decisions made in the core platform.
• Documentation and Monitoring agents record the new interaction pattern and watch for silent failures — a card that renders but doesn't write back is a governance problem, not a UX inconvenience.

A common objection to lightweight approval surfaces is that they weaken governance. Done correctly, they don't: the core platform remains the system of record for the decision, the timestamp, the approver identity, and the resulting record state. Slack and Teams are the surface where the human acts; they are not where the history lives.

• Approval and rejection events are written back to the native approval/workflow object on the core platform — same audit fields, same reporting, same compliance exports.
• Identity is passed through, not assumed — the write-back carries the actual approver's identity, not a shared service account.
• The interaction surface changes; the record of what happened does not.

Whether an approval-only or notification-only user can move to a lower-cost license tier — or off a named-user license entirely — depends on the specific vendor agreement, the edition, and how that vendor defines a "user" for licensing purposes. Some platforms have an approved lower-cost or external-facing license type built for exactly this pattern; others count anyone interacting with the system, regardless of interface, as a full user.

• We map each candidate workflow to the platform's actual license terms before recommending a change — a Cost Analysis and License Optimization agent function, not a guess.
• Where a platform offers an approved lightweight or external user type built for limited, transactional access, we use it. Where it doesn't, the seat stays as-is and only the interaction pattern changes.
• Any projected license-mix change is illustrative until it's checked against your current contract, edition, and vendor documentation.

The pattern repeats across the platforms we implement and operate, with the specific mechanism differing by vendor:

• Salesforce — approval processes and Flow-driven approvals routed to Slack via approved actions, with the Approval History object as the record of truth.
• ServiceNow — approval and notification tasks surfaced as Teams adaptive cards, writing back to the native Approval table.
• Microsoft Dynamics — Power Automate-driven approvals surfaced natively in Teams, using Dynamics' own approval entities.
• NetSuite — workflow approval actions triggered from Slack or Teams messages via NetSuite's SuiteFlow and integration points.

Each of these is scoped and validated per customer, not deployed as a generic template — approval configurations, custom objects, and license editions vary enough that a pattern fitting one org may not fit another.