Governance Hinders Citizen Integrator Adoption
Tray.io
Tray only works at full value if enterprises let non engineers build real workflows, not just submit tickets to IT. In practice, the product promise is that a sales, marketing, or ops manager can drag together steps across Salesforce, Slack, Snowflake, or internal APIs and put the workflow into production. If security teams lose trust, those users get pushed back into approvals, locked down permissions, and narrow templates, which turns Tray from a broad workflow layer into a more limited IT tool.
-
This is the core tradeoff in low code integration. Tray has grown by selling a low code platform to enterprise IT and business technologists, and it prices like enterprise software with both seat and usage expansion. That model depends on widening the pool of builders beyond central engineering teams.
-
The alternative is a much tighter model where the software vendor owns the integration experience itself. Embedded integration vendors like Alloy win by letting SaaS companies ship native looking integrations while keeping control of permissions, UX, and maintenance. That is safer, but it moves workflow creation away from the business user and back toward product and engineering teams.
-
The competitive benchmark is tools like Zapier and Make, which trained the market to expect non technical automation builders, but mostly in lighter use cases. Tray is trying to bring that same accessibility into more complex enterprise workflows, where governance matters more because the workflows touch sensitive systems and higher value processes.
The market is heading toward a split. Simple automation will keep moving to broader groups of employees, while high consequence workflows will require stronger policy controls, audit logs, and role based limits. Tray is already building around that with governance, trust, and enterprise control features, and the winners in iPaaS will be the vendors that let more people build without forcing IT to give up oversight.