The collaboration platforms that won did not win on messaging. Messaging is a solved problem and has been for decades. What separated the platforms that became infrastructure from the ones that became features was the app directory: the list of other systems that could push information in and accept instructions back out. By 2015 this had become the explicit strategy. Platform vendors courted developers, published APIs, built directories, and marketed the count of available integrations as a headline figure. The pitch to buyers was that the messaging tool would become the place work happened rather than the place work was discussed — deployments announced, tickets triaged, approvals granted, alerts acknowledged, all without leaving the channel. The pitch was broadly correct, and it created a dependency that most buyers did not price.
Why integrations became the moat
The competitive logic is straightforward once you see it. A messaging platform with no integrations is easy to replace — export the history, onboard everyone somewhere else, absorb a few weeks of friction. A messaging platform with sixty active integrations is not, because replacing it means rebuilding sixty pieces of workflow that different teams depend on and that no single person understands. Each integration is individually trivial to set up. That is the point. A developer connects the monitoring system in ten minutes because permission was not required and no project was needed. Multiply that by three years and several hundred employees, and the platform has accumulated a web of operational dependencies that no one planned, no one documented, and no one can enumerate on request. This is switching cost created by convenience, which is the most durable kind. It also explains why the eventual winner in this category was the platform with the strongest distribution rather than the best product: once integration density is the moat, the vendor whose platform is already installed everywhere accumulates density fastest.
The two directions, and why one is riskier
Integrations fall into two categories with very different risk profiles, and organisations routinely govern them as if they were the same thing. Inbound integrations push information into the platform. Build notifications, monitoring alerts, ticket updates, form submissions. The risk here is volume rather than security. A channel receiving four hundred automated messages a day is a channel nobody reads, and the alerts that matter disappear into the stream. The failure mode is quiet: the integration works perfectly and the information stops reaching anyone. Outbound integrations let the platform act on other systems. Approve a request, restart a service, update a record, trigger a deployment, release a payment. These carry real authority, and they are typically configured with broad credentials by whoever set them up, because narrowing the scope required more work than accepting the default. The security consequence is that the collaboration platform becomes an authorisation path into production systems, governed by whatever the messaging platform's own access controls happen to be. Someone who compromises a single user account may be able to trigger actions in systems that account has no direct access to. Very few organisations have mapped that path, and it does not appear on network diagrams. The corresponding governance question — who may install an application that holds an access token for a business system — is usually answered by default, and the default on most platforms is "any user".
| Integration direction | Primary use | Control emphasis |
|---|---|---|
| Inbound | Post alerts, ticket changes and status | Filter at the source; route to a reader; separate automated feeds from conversation |
| Outbound | Trigger changes in a connected business system | Approve installation, narrow credentials, assign ownership and retain the decision in its system of record |
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
The signal problem nobody solved with technology
The promise was consolidation: all the information in one place. What most organisations got was a firehose. The pattern is predictable. A team connects its monitoring system, then its ticketing system, then deployments, then error tracking. Each addition seems reasonable. Within a year the channel produces continuous automated output, humans stop reading it, and the team invents a side channel for actual conversation — which is where the important information now lives, unintegrated. The organisations that avoided this treated notification design as a real discipline: separate channels for automated output and human discussion, severity filtering at the source rather than in the platform, alerts routed to the person who can act rather than broadcast to a team, and periodic review of which feeds anyone still reads. None of that is technically difficult. It is just work that has no owner by default, and integrations are installed by people who are not thinking about the aggregate. The useful test: pick your busiest integrated channel and ask who read it yesterday. If the answer is nobody, the integration is producing noise with an operational cost and no benefit.
Practical Guidance for Integration Strategy Review
- Inventory every installed application and bot, with an owner and a business justification for each. Most organisations running this exercise for the first time find that a third are unowned and a quarter are unused.
- Govern applications that hold write access differently from those that only post messages. Approval, scoped credentials and periodic review for anything that can act on another system; light-touch for anything that only notifies.
- Audit the permission scopes each application actually holds. Applications frequently request far broader access than they use, and the scope granted three years ago is still in force.
- Separate automated feeds from human conversation at the channel level. Mixing them destroys both, and it is the most common reason integrated channels stop being read.
- Filter at the source, not at the destination. Sending everything and expecting people to ignore most of it is how alert fatigue is manufactured.
- Review integration usage quarterly and remove what nobody reads. Each retired feed improves the signal of everything that remains.
- Record which integrations are operationally critical. When the platform has an outage, you need to know immediately which workflows have stopped, and that list should exist before the outage.
- Assess the integration estate before committing to any platform migration. The rebuild cost is usually the largest single line in a migration and the last one anyone estimates.
The Regional Dimension
The integration picture in Gulf organisations looks different from the pattern the platform vendors designed for, in ways that change what a review should examine. The most important integrations are frequently with government and banking systems rather than with developer tooling. Notifications tied to wage protection submissions, visa and labour file status, customs clearance, e-invoicing acknowledgements and bank payment confirmations are the alerts that actually matter to a regional operation. Most of those systems were designed for portal access by a human, not for outbound webhooks, so the integration is either scripted by someone internally, handled by a robotic process automation bot, or does not exist. Each of those approaches carries a credential and continuity question that a standard app-directory review will miss entirely. WhatsApp remains the channel of record for a large share of operational coordination, which produces a specific integration gap: alerts land in a sanctioned platform that people check occasionally, while decisions happen in a messaging app that no system integrates with and no archive captures. Reviews that only examine sanctioned-platform integrations describe half the workflow. The pragmatic response is to define which categories of alert must be actioned in the governed platform and to accept that informal coordination will continue elsewhere. Integrator dependency reappears here. Where an external partner built the automation, the bot tokens, webhook endpoints and service accounts are frequently registered under the integrator's identities rather than the client's. That means the client cannot audit them, cannot rotate them, and loses the integrations at contract end. Ask whose account owns each application — the answers are often uncomfortable. Turnover completes the picture. High workforce mobility means integrations built by individuals become orphaned quickly, running under a departed employee's personal token until it expires or the account is deactivated — at which point a workflow stops with no obvious cause. Service accounts with documented ownership are the fix, and they need to be policy before they are convention.
The objection worth taking seriously
The honest criticism is that integration count is a vanity metric and that most of the workflow value claimed for these platforms never materialised. A directory with two thousand applications tells you nothing about whether your organisation uses six of them well. In practice most companies run a small number of genuinely valuable integrations — typically alerting, ticketing and one or two approval flows — alongside a long tail installed during an enthusiastic first month and never touched again. The marketing figure measured ecosystem breadth; the operational reality was concentrated in a handful of feeds. There is a sharper version of the objection. Integrations moved work into the messaging platform where it is transient, unstructured and poorly searchable. An approval granted in a channel is a decision with no record in the system that should hold it. An incident worked through in a thread leaves no case history. The platform became a place where things happen and nothing is retained in a form the business can use later — which is a regression from the systems of record that the integrations were connecting. The balanced position is that integrations are valuable for awareness and for low-consequence actions, and dangerous as a substitute for systems of record. Alerts, status and triage belong in the channel. Approvals, decisions and anything that will be audited should be executed in the system that holds the record, with the channel used to prompt and confirm rather than to replace it. Organisations that drew that line kept the benefit without the archival problem.
Common Questions
How many integrations should we actually run?
Fewer than you have. The useful question is not a target number but whether each feed has a reader and each action has an owner. Estates that grow past a few dozen active integrations without review are almost always carrying substantial dead weight.
Who should be allowed to install applications?
Anyone, for message-only integrations; a controlled process for anything holding write access or a credential to a business system. Blanket restriction pushes people to workarounds and loses you the visibility entirely, so make the permitted path easy.
What is the biggest hidden risk?
Accumulated permission scope. Applications installed over several years hold tokens into finance, HR, source control and cloud infrastructure, granted by individuals, reviewed by nobody. That set of tokens is a lateral movement path that most security assessments do not examine.
How do AI assistants and agents change this?
They make the integration estate the product rather than a convenience. An assistant is only as useful as the systems it can read, and only as safe as the narrowest credential it holds — so the sprawl that was previously an untidy inventory becomes the direct determinant of both capability and blast radius. Two things follow: scoped, auditable, per-agent credentials instead of inherited service accounts, and a record of what the agent read and did. Organisations that never cleaned up their application inventory are now granting reasoning systems access through it.
Integration Strategy Review — count the integrations that hold write access to a business system, then ask who approved each one; that number is your real integration strategy.