自社システムで来訪者バッジのコードを発行する

自社の入退室管理が生成した認証コードしか受け付けない建物があります。そうした拠点では Offision が 生成した QR はバリアの前で役に立たないため、Offision の側を待たせる必要があります。バッジは作られる ものの送られずに保留され、自社の来訪者管理システムがそのバッジの持つコードを供給し、そこで初めて 来訪者の手元へ届きます。

準備するもの

• 自前でバッジコードを生成でき、訪問が作成されたときに呼び出しを受けられる来訪者管理システムまたは入退室管理システム
• ゲートの記事で作った API 資格情報。同じものでよく、スコープの追加も不要
• テスト中は訪問を止めてもかまわない拠点。この設定を入れた瞬間から、その拠点のバッジはすべて送られなくなります
• 半日程度。2 本の呼び出しが中間で噛み合う必要があり、どちらも単体では間違えやすいものです

1. 外部バッジコードを必須にするを有効にする

その拠点の訪問ポリシーを開き、外部バッジコードを必須にする を有効にします。セキュリティ の ページにある来訪者バッジのグループの中にあります。

2. コードを供給する

向きの異なる 2 本の呼び出しを使います。ワークフローで組み立てるのは、戻ってくる側が正しいバッジに たどり着く必要があるからです。

• 行き。 バッジ作成をきっかけにワークフローが訪問情報を自社システムへ送ります。自社側はそこから 来訪者と期間を読み取り、コードを発行します。
• 戻り。 自社システムがそのコードを Webhook に返します。外部コードを記録 を選んだ 来訪者バッジを更新 アクションがそれをバッジに記録し、それがバッジのメールの送信も解除します。

受け側トリガーの 応答モード は 実行完了まで待機 にしてください。既定の 即時応答 (202 Accepted) では、Offision が受け付けた時点で 202 が返るだけで、コードが実際に記録された かどうかは自社側にわかりません。つまりコードの記録に失敗したバッジと成功したバッジが区別できず、 それに気づくのは来訪者本人になります。

3. 来訪者に何を見せるかを決める

これ以降、バッジの QR が持つのは Offision の uid ではなく 自社の コードです。それがこの設定の狙いで、 自社のリーダーは Offision を呼ばずに自社システムだけで照合できます。

同じ場所に 2 つの設定が並んでいます。どちらも来訪者の手元に届くバッジの見え方の話です。

4. 動作を確認する

• 新しい訪問。 その拠点で 1 件作ります。バッジは Offision に現れ、まだ メールは送られない はずです。
• 往復。 自社システムが呼び出され、そのコードが数秒のうちにバッジに現れるはずです。バッジのメールは そのあと自動的に送られます。
• バッジそのもの。 来訪者が受け取ったものを開きます。QR は自社のコードを持ち、印字されるコードは 上の 2 つの設定で選んだとおりになっているはずです。
• 読み取り。 同じコードをチェックインの呼び出しに送ります。同じ来訪者に解決されるはずです。

最後の 1 つは、読み取り後に Offision を呼ぶ予定のない拠点でも試す価値があります。バッジに記録された コードが、自社システムが発行したつもりのコードと微妙に違っていることに気づけるのはここだからです。

うまくいかないとき