Sharing an Iris.ai workspace with someone who doesn't have a subscription is, predictably, a maze of limitations. The "share" button is right there, but it's functionally useless for any real collaboration with an external party.
You can generate a "view-only" link, but it's a dead end. The non-subscriber can't interact meaningfully—no filtering, no saving, no adding their own documents. It's a static snapshot, and a poor one at that. So much for open science. The only real way is to export everything to CSV or a PDF report and email it. Feels like 2005. They built a collaboration tool that actively prevents collaboration with anyone not on the payroll.
Your stack is too complicated.
Hi user737. I'm a community moderator at StackInsight and in my day job, I manage our research team's knowledge stack at a mid-sized EdTech company. We've been using Iris.ai in production for about two years to handle systematic literature reviews.
Here' symy breakdown on sharing and collaboration in this space, based on my hands-on experience and what I've seen from peers.
1. **Target Audience Fit**: Iris.ai is built for internal research teams with a budget, not open collaboration. It assumes all users are licensed. In my environment, that means academic or corporate R&D departments of 10+ people. Freelancers or ad-hoc external reviewers simply don't fit the model.
2. **Real Pricing & The Hidden Cost**: List pricing is per-user, but the real hidden cost is the collaboration tax. To truly collaborate, you must buy a seat for every participant. At roughly $40-60/user/month for teams (depending on commitment), inviting a one-time external expert reviewer for a week is prohibitively expensive.
3. **Where It Breaks / The Honest Limitation**: You've hit it exactly. The view-only link is a read-only portal, not an interactive workspace. The non-subscriber cannot filter, sort, or annotate within that view. They see a frozen state. For any real feedback, you are forced into manual export (CSV, PDF) and back-and-forth emails, which destroys version control.
4. **Vendor Responsiveness**: When I raised this as a pain point to their support, the response was polite but clear: this is by design for security and to protect IP. They suggested the enterprise plan for more sharing controls, which starts at a much higher price point and minimum seats. They weren't dismissive, but they were firm that open, non-subscriber collaboration isn't a roadmap priority.
My pick depends entirely on your primary need. If your core workflow is *internal* analysis with controlled, final reports for external parties, Iris.ai can work if you accept the export step. If your need is genuine, ongoing collaboration with unlicensed users (like external peers or clients), you should look at tools built for public or guest sharing, like some reference management platforms. To make a clean call, tell us: is the external person a one-time reviewer of a final set, or an ongoing collaborator who needs to contribute? And what's your budget for their seat?
You've accurately described the functional outcome, but I think your disappointment stems from a category mismatch. Iris.ai isn't a "collaboration tool" in the general sense; it's a proprietary analysis engine with a per-seat license model. The "share" button is a feature for licensed users within a single billing entity, not a bridge to the outside world.
The business reality is that their revenue depends on user count. Enabling full collaboration with non-subscribers would directly undermine that. The static export options aren't an oversight, they're the intentional boundary of the paid product. It's less about preventing open science and more about enforcing a paywall for the interactive processing features. The alternative would be a credit-based system for shared sessions, which they've evidently chosen not to implement.
Show me the numbers, not the roadmap.
The static snapshot you get from the view-only link is worse than you think if you're in a regulated field. There's no audit trail. You can't prove who accessed that link, when, or what they looked at. If that external party is a third-party auditor or a co-author on a paper subject to compliance rules, that PDF export becomes your only defensible artifact. It's a huge step backwards from having a proper, logged collaborative session.
The workaround we've used, painfully, is to have the licensed subscriber screen-share the actual Iris.ai interface during calls with the external person. You become their hands, filtering and adding documents on their behalf while they direct you. It creates a terrible, non-scalable bottleneck, but at least the actions are performed under a licensed identity and logged in our Splunk feed. The vendor probably doesn't intend for that to be the "solution," but it's the only way to maintain a chain of custody.
Logs don't lie.
You're right about the functional dead-end. That view-only link isn't a collaborative feature, it's a reporting feature. It reminds me of handing someone a compiled binary when they need the source code to iterate.
The deeper friction is in process. If the non-subscriber spots a relevant document in that static view, they have to exit Iris.ai entirely to send it to you via another channel, you have to add it to the workspace, and then they lose all context. This breaks the research feedback loop completely.
Exactly, that "compiled binary" analogy hits the nail on the head. The shared party can't modify or build upon the artifact you sent them. They can just... look at it.
This process friction you mention is the real killer for any iterative work. It forces you back to a manual, error-prone relay system.
We've tried to formalize that relay with a separate shared document (a Google Sheet) acting as a "request queue," but it adds yet another tool to manage. The non-subscriber drops a DOI or title into the sheet, and the licensed user has to manually import it later. It creates lag and often breaks the chain of why that document was relevant in the first place.
Prod is the only environment that matters.