@debryc さんからのこちらの質問を受け、クラウドストレージ（当社の場合は NextCloud インスタンス）とチャット（当社の場合は Mattermost）と Discourse フォーラムを円滑に連携させるために実施した作業について、簡単にまとめました。
長文になりますので、詳細は矢印をクリックするまで非表示にしています…
全文（長文）
まず断っておきますが、私はこのシステムの開発者ではありません。これはテックチームの別のメンバーが C#/.NET で作成したものですので、技術的な詳細な質問にはお答えできません。私が説明するのは、私たちが解決しようとした課題と、それに対して行った取り組みです。
背景：以前は、ディスカッション、リアルタイムチャット、ファイルストレージの統合を提供する統合システム（Basecamp）を使用していました。しかし、そのシステムには構造的、セキュリティの両面で多くの不満な点があったため、組織全体を新しいオープンソースシステムへ移行することを決めました。
私たちは多くの調査と評価を行いました。いくつかの選択は利便性によるものでしたが、他のものは要件に最も合致するものを選んだものであり、またさらに他のものは、1 万人のユーザーにとって移行経路をできるだけ苦痛のないものにする必要があったためです（ユーザーには技術に詳しくない人が多く、また技術アレルギーを持つ人も相当数おり、それぞれが強い意見を持っています。全員を満足させるのは容易ではありません！）。
結論から言うと、私たちは 3 つの独立したコンポーネントを採用しました。リアルタイムチャットを提供する Mattermost、より慎重な議論を行う Discourse、そして安全なファイルストレージと共同編集を提供する Nextcloud（ネイティブの Basecamp ストレージと Google ドキュメントの組み合わせを代替）です。これらすべては、自前で管理するサーバー上でホストされています。
そこで、3 つのシステムで必要なログインを比較的シームレスに連携させ、自動的にユーザーアカウントを作成し、適切なアクセスグループ/フォーラム（Discourse）、共有ストレージグループ（Nextcloud）、チームとチャンネル（Mattermost）にユーザーを割り当てる方法が必要になりました。
組織には所在地や機能別に数百の独立したグループ/チームがあり、ユーザーは複数のグループに所属する可能性があります。一部はクローズド、一部は誰でも自由に加入できるオープンなものとなっています。
最初の課題は、3 つのシステムでユーザーアカウントを作成し、初期段階でユーザー名（互いに認識できるように）とパスワード（少なくとも 1 組の認証情報を記憶・保存し、最終的には 3 つのシステムへのシングルサインオンを実現するため）を統一することでした。
また、アカウント作成時に人を正しいグループに割り当てる方法も管理する必要がありました。旧システムでは実際のグループとオンライン上のグループの間に良好なマッピングが存在しなかったため、単純に移行することはできませんでした。
そこで私たちが考案した解決策は、ユーザーアカウントの管理を行い、3 つのシステムの API を使ってユーザー情報の作成と更新を行う「Hub」と呼ばれる別のウェブサイトです。
この Hub は、各グループ（またはグループのセット）の「テックチャンピオン」が新しいサービスに人を招待できるようにもしています。これにより、適切な人だけがそれぞれの場所に所属することを保証しています。
つまり、ユーザーは新しいサービスに参加するための招待メールを受け取り、Hub へのワンタイムリンクを通じてユーザー名とパスワードを作成します。その後、この情報が自動的に 3 つの個別サービスに対応するユーザーアカウントを作成するために使用されます。
Hub は、ユーザーがアクセスすべきグループ/フォーラム、チーム/チャンネル、ストレージエリアも把握しており、API を通じてそれぞれの場所でユーザーを追加します。
進化に伴い、Hub にはさらに多くの機能が追加されました。現在ではユーザーがこれを使ってチャンネルやフォーラムを見つけ、参加をリクエストしたり、テックチャンピオンやユーザー向けのさまざまな管理機能を利用したりできるようになっています。
また、現在では一種のシングルサインオンも提供しており、Hub でログインすれば、ワンクリックで他のサービスのいずれかにログインできるようになりました（この作業の一部には、標準的な企業向けソーシャルメディアタイプのログインを除外する作業も含まれていました）。
チャットの統合やファイルストレージの扱いを単一のシステムで行う方法（3 つすべてがその可能性を一部持っています）をいくつか検討しましたが、いずれも大きな妥協を伴い、最終的には Basecamp のような「委員会によって設計された馬（ラクダ）」になってしまいます。コア機能ごとに専用の良質なソリューション（サラブレッド）を維持し、それぞれをうまく機能させる方が良いでしょう。