365と連携し、クラウド上で様々なワークフローを実現できるサービスです。ご導入頂いているお客様では既に様々な「お金」に関するワークフローをご利用いただいていることでしょう。一般的には上長の承認・決裁が必要な稟議書、精算書などに関するものがほとんどかと思いますが、そのようなワークフローにおいて決裁金額に応じて処理を切替えたいという御要望をお受けすることがあります。Flowを使って決裁額に応じた承認ルートの分岐方法をご説明します。本記事では以下の稟議フローの一部を使って説明していきます。申請者からの稟議申請に対して直属の上司である課長が承認・決裁する場合、その決裁額によって以下のように処理が分かれるものとします。20万未満:課長による決裁ができる。20万以上:承認のみ。決裁の判断は次の承認者・決裁者に委ねる。課長は決裁金額に応じて承認者となる場合もあれば、決裁者になる場合もあります。これは、決裁金額によってどちらか一方の処理を排他的に実行するものと考えることができます。Flowでは上記のようなケースを実現する場合、必要な処理を実行するボタンを追加し、そのボタン毎に有効/無効または表示/非表示の条件設定を行うことで、表現することができます。以下、このボタン表示切替に必要な設定方法を説明します。経路毎に必要な処理を追加するその経路で承認/決裁者が行うべき処理を「経路」→「(経路名)」→「実行可能な処理」に定義します。処理するためのボタンを追加しています。ボタン表示制御のためのスクリプトを指定する上記で追加したボタンの名称をクリックし、「ボタン表示切替」の編集リンクをクリックします。すると、スクリプト編集画面が開きますので、そこで判定処理のためのスクリプトを記述します。「決裁」ボタンは入力フォームの項目「決裁金額」が20万未満の場合のみ表示するようにしたい場合、以下のようなスクリプトを記述します。false;}同様に「承認」ボタンにも表示制御用スクリプトを指定します。承認ボタンの場合は上記のスクリプトとは逆の条件判定になります。スクリプトを記述したら、「スクリプトを確認する」リンクをクリックし、動作検証を行いましょう。false;}指定すると、各ボタン名に以下のようなアイコンが表示されます。以上の設定内容を踏まえた申請モデル「稟議書」を作ってみました。以下のスクリーンショットでは「費用または金額」が決裁金額に該当するものとします。申請者がタブレット購入額として160,000円を稟議申請した場合、20万未満となりますので、課長承認時には以下のように決裁ボタンのみ表示します。パターンA:決裁金額が20万未満の場合(→決裁)一方、申請者がノートPC購入額として360,000円を稟議申請した場合は、決裁金額が20万以上となりますので承認ボタンのみ表示します。パターンB:決裁金額が20万以上の場合(→承認)以上の通り、決裁金額による条件判定でボタンが切り替わることがお分かりいただけたと思います。Flowのボタン表示制御を利用することで以下のメリットを享受できます。ユーザの誤認識による間違ったボタンの押下リスクが防止できる画面上に説明や注意書をどれだけ記載したとしても、人はミスする生き物であり、ミスは防ぎきれないでしょう。適切にボタン表示切替を利用することで、余計なボタンを押さず、ミスを防止することができます。ワークフローを一元管理できる適切にボタン表示切替機能を指定することで、申請モデルを複数分ける必要はありません。ユーザの学習コストおよび情報システム部のサポートコストが下がる画面のボタン表示もシンプルとなり、ユーザの教育コストおよび情報システム部門のサポートコストも下がることにつながるでしょう。Flowのボタン表示制御機能を利用することで承認経路を変更する方法をご紹介しました。お客様へご説明するとき、「え?スクリプト?難しいんじゃない?」と不安がられることもありますが、書き方を少し覚えていただければ、すぐご活用いただけると思います。スクリプト形式で記述できるからこそ、様々な条件判定が記載でき、拡張性も高いです。注意点としましては、稟議書の申請モデルを1本にするために複雑な判定処理を記述してしまうと、ボタン毎に同様の記述が必要となり、修正発生時のメンテナンスが大変になる場合もあります。そのため、運用とメンテナンスを考慮しつつ、申請モデルを1本にまとめるべきか、分けるべきかご検討いただければと思います。アクセスを制御する運用のパターンをいくつかご紹介しました。今回は、もう一方の主要機能「シングルサインオン」についての運用パターンを見ていきます。シングルサインオンシングルサインオン(SSO)とは、簡単に表現すると、「一回のログインをもって、複数のサービスを利用可能にする」という仕組みです。高度な連携が出来る既定のサービスをはじめとして、SAML2.0に対応するサービスや、SAML2.0に対応していない一般的なWebサービスも、SSOの対象サービスとして登録することができます。ログインすることでこれらのサービスに個別にログインすることなく、利用することができます。Provider(SP)と言います。IdPで、登録されるサービスがSPということになります。扱えるSPを簡単にご紹介します。多くのサービスが既定のSPとして利用可能です。SSOの文脈では認証の連携をするのみですが、既定のサービスでは、認証以外にも、プロビジョニングの機能を提供するなど、より高度な連携が可能です。Luck!、PrimeDriveなどに対応しています。SAML2.0対応のSPSAML2.0は、SSOの仕様として事実上の標準となっており、多くのサービスがSPとして動作します。仕様として定められているものの、実際の実装にはサービス毎に若干のばらつきがあります。個別の設定をすることでSPとして登録することが出来ます。SAML2.0に対応していないSPSAML2.0に対応していなくても、SPとして登録することができます。昨今の多くのサービスはSAMLに対応していますが、古くから社内で使われているサービスや、SSOを意図していない内製のサービスなどは、この方式でSPとして登録することができます。Gateでは前述したSPを利用することができますが、お客様は実際にどのように運用されているのでしょうか。以下、お客様環境での運用ケースをご説明していきます。365といったメジャーなクラウドサービスの利用のために、アクセス制御を目的として導入するケースが多くあります。365に移行する場合、多くのニーズは、移行先で満たせます。業務の内容によっては、どうしても既存のサービスを利用しなければいけない場合があります。既存サービス」というような運用となります。既存サービスを置き去りにせず、SSOの世界に入れることで、利便性が損なわれることがありません。365のような多機能なサービスとは別に、特定の単機能に特化したサービスも多く提供されています。365を使い、足りない部分を単機能のクラウドサービスで補うような運用をされています。Suiteを入れて、営業部門にはSalesforceを、サポート部門にはZendeskを、経理部門にはさらに別なクラウドサービスをというように、各部門向けに特化したサービスを選んで追加する形です。ニーズは各部門にあるので、部門独自で導入してしまうケースも見受けられます。その場合は、ID管理が別になりますし、全社で使っているサービスと部門で使っているサービスは別にログインしなければいけません。その場合は、SPとして登録して、SSOの仲間にしてしまいます。メジャーなサービスは既定のSPとして提供しています(今後も対応を増やしていきます)し、現時点で対応できていなくても、汎用SAMLを利用すれば、SPとして登録可能です。高度な機能が月単位で少人数でも利用可能になっている時代です。トッピング感覚でSSOに取り込むことでシームレスにサービスを利用できます。シングルサインオンでユーザの利便性を追求し、さらに...ビジネスで使うサービスは、今後も増加していきますし、捨てきれないレガシーサービスもあります。これらをまるっとSSOに取り込むことで、利用者は本来の仕事のために頭と時間を使うことができます。認証を一箇所で管理することで、前回の記事で触れた「アクセス制御」も一元管理できます。ひとつのポイントの「ID管理」も一箇所で完結します。ユーザの利便性を追求することと、セキュリティの強化および、管理工数の削減を同時に実現可能です。いかがだったでしょうか。レガシーシステムも、最新のクラウドサービスも同時に利用するお手伝いができます。「新しいサイト」が利用できるようになりました。「新しいサイト」は、これまでのサイトの延長線上には無く、コンセプトから何から大幅に変更されています。便利になっている反面、いくつかの不安な点もありました。はじめ埋め込み型の「ガジェット」の挿入の可否についてでした。公式アナウンスは、およそ以下の通りでした。一方で、ガジェットについては、以下のような情報がありました。貴社を含め多くのパートナー様がガジェットを提供いただいている状態であるため、そう簡単に廃止できる機能でないとは思っておりますが、現時点でははっきりとしたことは申し上げられません。この度、上記の状況に動きがありましたので、ここで紹介させていただきます。新しいサイトでのガジェットへの対応ということで、以下の記事が掲載されました。ついても、新しいサイトで利用していただくことができるだろうとの判断の下、現在対応可否の詳細について調査を進めております。対応させることも検討しております。お届けできるよう、邁進いたします。365等の様々なクラウドサービスに対して、SSOやアクセス制御を実現することができるセキュリティサービスです。ネットワーク、端末種類など対するアクセスルールを、ユーザやグループ毎に設定することができます。これにより細かいアクセス制御が可能となっています。今回は、そのアクセス制御を実現している仕組みについてご説明したいと思います。しているクライアント端末などに応じて、利用するサービスや認証方法を変えたい場合もあるかと思います。以下のようなアクセスポリシーを社内で設定したいとします。Suiteは社員全員が利用できるものとする。アクセス時のクライアント端末は社内のPCブラウザからのアクセスを基本とするが、社外からの利用は会社が許可した端末からのみアクセス可能とする。その他、営業部に所属する社員はSalesforceへアクセスできるこのようなポリシーを踏まえて適切なアクセス制御を行いたい場合、「誰が」「どの端末で」認証しようとしているかに加えて、「誰が」「どの端末で」「どこに」アクセスしようとしているかもチェックする必要があります。Gateではこのようなチェックを適切に行えるようにするために、認証を行ったユーザを識別し、ある特定のユーザ・グループに対してアクセス先サービスを限定したり、端末毎に認証方式を変更する必要があります。Gateでは認証フェーズと認可(アクセス権限)フェーズの2フェーズに分けて処理するようになっており、これにより細かいアクセス制御が可能となっています。下図は、認証/認可処理フェーズの流れをまとめたものです。以下に各フェーズ毎の処理概要を説明します。認証フェーズ認証フェーズでは管理者が定義した認証ルールに基づき、ログインを試みるユーザーが誰であるかを特定するものになります。認証ルールは、どの端末種類からの認証時にどの認証方式を要求するか定義します。AD/LDAP認証等を指定します。認証ルールに複数該当していたとしても、最初に認証が失敗した時点で即認証エラーとなります。認可(アクセス権限)フェーズ認可(アクセス権限)フェーズでは、上記1の認証フェーズで特定されたユーザに対して、管理者が定義したアクセス権限ルールに基づき対象サービスへのアクセス権があるかチェックします。いった条件を組み合わせて定義します。認証が成功したユーザは設定されたいずれかのルールにマッチするアクセス手段であれば、アクセス成功とみなします。いずれのルールにもマッチしなかった場合は、アクセス失敗となり、対象サービスを利用することができません。アクセス権限の詳細については以下の記事をご確認ください。-いかがだったでしょうか。Gateでは認証・認可の2フェーズに分けていることで細かいアクセス制御が可能となることがお分かりいただけたと思います。別のセキュリティサービスを使っており、アクセスポリシーを細かく設定したいができない点でお困りの方がいらっしゃいましたら、ぜひお問い合わせください。365と連携して、多様な「ワークフロー」をクラウドで実現することができます。これまでに、多くのお客様のご要望を実現しするために、きめ細やかな機能を実装してきました。お客様がやりたいことは千差万別で、全てを実装済みの機能としてご提供するのは困難です。Flowでは、一部の機能でお客様自身が拡張できる仕組みをご用意しています。今回はそのような拡張の実例をご紹介します。細かな入力チェック申請者は、フォームに入力する時に様々な値を入れます。ワークフローとしては、数値を期待しているのに、文字列が入れられたりすると、後続の処理で困るため、手で直さなければならない場合もあるでしょう。そのため、入力フォームでは、入力された値をチェックする「入力チェック(バリデーション)」という機能が必要です。以下の例で、フォームにメールアドレスが入力されることを期待する入力チェックをご紹介します。カスタムバリデーション入力チェックのルールをJavaScriptで実現します。申請モデルの入力チェックのカスタムバリデーションの「スクリプト」で、入力された値が、期待されたものなら、trueを返し、そうでない場合には、falseを返すようにします。メールアドレスが期待される場合には、以下のようなスクリプトになります。入力された値が、メールアドレスを示す文字列にマッチしない場合に、falseを返しています。!は否定(〜でない)。該当するものでないとなる。true;「スクリプトを確認する」の機能を使って、その場で動作の確認をすることもできます。任意のスクリプトを設定することで、入力値が、定められた形式(社員番号や商品コードなど)であることをチェックできます。スクリプト内では、他の入力フォームで入力された値や、日付、申請者の情報などを参照することもできますので、より柔軟なチェックが可能です。入力された値に対応したメッセージを表示する上の例は、入力される値を期待するものに限定する機能でした。次の例は、入力された値に対応して、特定のメッセージを表示する機能です。ここでも、JavaScriptが使えます。カスタムラベル入力フォームの形式として「カスタムラベル」を使います。特定の値を参照して、定義した条件に合致した場合に、特定の文字列を返します。返された文字列が、申請フォームに表示されます。以下の例では、処理した日付を参照して、曜日を表示することができます。"曜日";スクリプトを確認してみましょう。確認するために任意の日付を入れられますが、実際の申請時には、プレースホルダの機能によって、申請された日付が自動で入ることになります。Flowでは、様々な機能でJavaScriptを使って、機能を拡張することができます。申請フォームの作りの柔軟さは、利用者の利便性を大きく左右します。Flowをご利用ください。あたりもあるでしょうか。03-6401-5211(平日9:00~17:30)お問い合わせ・資料請求サポートGluegentの製品・サービスをご利用の方へGluegentが提供するサービス、製品に関する新しい情報を入手したり、機能に関する提案を共有したりすることができます。