LikePay Academyが「スーパーサイトAcademy」に変わりました。詳しくはこちらです。

ロジックの概要

ネイティブのWebflow自動化を使用して、サイトをより強力で有用なものにしましょう。

この投稿は公式のWebflow Universityを元に作成しました。翻訳したテキストと画像は引用元のものを使用する場合があります。引用元はこちらです。

Webflow Logicを使用すると、Webflowデザイナー内からセールスリードを収集しルーティングしたり、顧客と連絡を取ったり、サイトコンテンツを管理したりなど、自動化されたワークフロー（「フロー」とも呼ばれます）を構築して実行することができます。

このレッスンでは、以下のことを学びます：

Logicにアクセスする方法

Webflow Logicを使い始めるには、左のツールバーにあるLogicアイコンをクリックしてLogicパネルを開きます。ここから、Flowsタブをクリックしてフローに関する高レベルの情報（フロー名、トリガー、トリガーソース、ステータスなど）にアクセスし、Flowエディタを使用してフローの構築、管理、テストを行います。

フローの作成と構築方法

フローは、トリガー、アクション、条件という3つの異なるパーツで構築されるロジックのシーケンスです。新しいフローを作成するには、Logic panelを開き、FlowsタブをクリックしてNew flowをクリックし、low editorに入力します。

Flow setting（フロー設定）では、新しいフローにname（名前）とdescription（説明）を付けて、フローの目的を明確にし、他のフローと区別することができます。ここでは、Flow IDも見つけることができます。このFlow IDは、トラブルシューティングのためにフローを識別するためのものです。

それから、フローの構築を始めるために、トリガーを選択し、アクションとユーティリティをFlowエディタキャンバス上の接続ポイント（つまり、ブロックを挿入できるポイント）にドラッグアンドドロップします。

重要：フローを構築する際に、各ブロックにはそのブロックの設定が構成されるまで黄色い「レンチ」アイコンが表示されます。ブロックの設定が構成されると、黄色い「レンチ」アイコンは緑色の「チェックマーク」アイコンに置き換わります。

注意：変更を適用せずにFlowエディタを閉じると、フローは下書きモードのままで、作業内容が保存されます。

フロー内のブロックを異なる接続ポイントにドラッグアンドドロップして配置することができます。また、ブロックを削除するには、ブロックを右クリックしてRemove blockをクリックするか、ブロックを選択してキーボードでDeleteキーを押します。

トリガー（Triggers）

すべてのフローはトリガーから始まります。トリガーとは、サイト内で発生するイベント（例：フォームの送信）またはサイト外で発生するイベント（例：webhook event）のことで、これによりフローが開始されます。

フローにトリガーを追加するには、Select a trigger starting this flowをクリックし、フローを開始するためのトリガーを選択します。次の2つのトリガーがあります：

Form submission：Webflowサイト上で選択したフォームが送信されたときに実行されます
Incoming webhook：外部サービスでイベントが発生したときに実行されます

注意： 1つのフローに対して1つのトリガーしか追加できません。

トリガーを追加したら、キャンバス上のトリガーブロックを選択し、Trigger nameフィールドにトリガーの名前を付けます。次に、選択したトリガーのタイプに基づいてトリガー設定を構成する必要があります（例：Form submissionまたはIncoming webhookなど）。

トリガーを削除または置き換えるには、トリガーを右クリックしてRemove triggerをクリックするか、トリガーを選択してキーボードでDeleteを押します。

任意のトリガーの出力（つまり、トリガーがフロー内の後続ブロックと共有する情報）は、Trigger settings > Outputタブで表示できます。

トリガーに続いて、アクション（例：メール通知送信、CMSアイテム作成、ユーザー招待など）を実行するか、ユーティリティで条件を設定することができます。

Form submission

フォーム送信トリガーを使用する場合、まずサイトにフォームを追加する必要があります。そして、そのフォームにフロートリガーを接続し、サイト訪問者がフォームを送信すると、フローが実行されます。

重要：フォームは一度に1つのトリガーにしか接続できません。つまり、1つのフォームを2つの異なるロジックフローのトリガーとして使用することはできません。

フローに接続するフォームを選ぶには：

Flow editor を開きます
キャンバス上のForm submission triggerブロックを選択してTrigger settingsを開きます
ドロップダウンメニューからフォームの名前を選択します

また、デザイナーキャンバスからもForm submission triggerを追加することができます。フォームを選択し、Element settings panelを開き、Form settings > Source を選択し、Source をLogicに変更します。次に、Add new flow または Browse flows を選択して、フォームを新しいフローまたは既存のフローに接続します。

フォームをフォーム送信トリガーから切断したい場合は、Flowエディタを開き、Trigger settings > Form ドロップダウンから Disconnect form をクリックします。

注意：スパムフィルタリングを有効にすることで、フォーム送信のスパムをフィルタリングすることができます。

Incoming webhook

Incoming webhook トリガーを使用すると、外部アプリケーション（Airtable、Make、Twilioなど）からJSON形式でリアルタイムのデータをフローに送信できます。言い換えれば、Incoming webhook トリガーによって外部アプリはフローに「コミュニケート」できるようになります。

Incoming webhook トリガーを使用するには、トリガー設定から Webhook URL をコピーし、このウェブフックにリクエストを送信するサードパーティのアプリケーションに貼り付けます。例えば、Mailchimpからウェブフックを送信して、それによってLogicフローをトリガーさせることができます。

注意： Incoming webhook トリガーを使用するには、外部のサードパーティサービスを使用してウェブフックとやり取りする必要があります。サポートや機能に関する質問については、直接サードパーティサービスにお問い合わせください。

アクション（Actions）

アクションブロック(Action blocks) は、フローが何を行うかを設定するためのものです。これらはオプションで入力データを受け入れ、ロジックの一部を実行し、常に出力データを提供します（つまり、後続のブロックと共有される情報です）。

アクションブロック の出力データ（つまり、ブロックがフロー内の後続のブロックと共有する情報）は、Block settings > Output タブで表示できます。

メール通知の送信（Send email notification）
CMSアイテムを作成（Create CMS item）
CMSアイテムを削除（Delete CMS item）
CMSアイテムを更新（Update CMS item）
CMSアイテムを検索（Search for CMS items）
HTTPリクエストを作成（Make HTTP request）
ユーザーを招待（Invite user)
ユーザーアカウントを削除（Delete user account）
ユーザーアカウントを更新（Update user account）

メール通知を送信する（Send email notification）

Send email notification ブロックを使用すると、フローがトリガーされたときに、サイトのコンテンツエディタやワークスペースのメンバーにカスタマイズされたメール通知を送信することができます。

Flowエディタでブロックを選択し、Send email notification block settingsに移動します。その後、Send to フィールドにアクセスして、利用可能なコラボレータのリストから個々のコラボレータを選択するか、All collaborators を選択してリスト内のすべてのコラボレータにメール通知を送信します。

注意：ワークスペースのメンバーではない人にメール通知を送信する場合、それらの人をサイトのコンテンツエディタとして追加するか、Make HTTP request blockを使用してデータを外部のメールサービスに送信する必要があります。サイトにコンテンツエディタを招待する方法について詳しく学ぶ。

メールの件名とメッセージは、トリガーからのダイナミックデータを使用してカスタマイズすることができます。次のデータタイプは、件名とメッセージフィールドで使用できます：

Plain
Email
Phone
Number
Text Area
Checkbox
Timestamp

コラボレータをメール通知から解除するには、名前の横にある「ゴミ箱」アイコンをクリックします。

CMSを作成（Create CMS item ）

Create CMS item ブロックを使用すると、ブロックがトリガーされたときにコレクション内で新しいCMSアイテムを作成することができます。ブロック設定には、選択したコレクションで利用可能なフィールドが表示されます。

注意：フローの設定を行う前に、CMSコレクションを作成しておいて、Create CMS item ブロックをコレクションに接続できるようにしておく必要があります。

重要: CMSにデータを追加する際は、プライバシーに配慮してください。例えば、リードを獲得し、そのリードに基づいてCMSのアイテムを作成した場合、それらのアイテムはサイトマップに追加され、あなたのサイトの読み取り専用プレビューリンクを持つ誰もがそれらを見ることができます。サイト訪問者に見られたり、検索エンジンにインデックスされるべきではない動的ページは、noindexにする必要があります。

このブロックを使用すると、フローからの静的入力または動的データ (フォーム送信からのトリガーデータやブロック出力データなど) を、CMS コレクションの基本情報やカスタムフィールドに直接マッピングできます。マッピングできるのは、同じデータ型同士のみです（たとえば、フォームのプレーンテキストフィールドのデータは、CMSのプレーンテキストフィールドにのみマッピングできます）。サポートされているバインディングは次のとおりです：

注意：現在、プレーンテキストフィールドからCMSのリンクタイプフィールドへのマッピングはサポートされていません。

重要：変数をCMSコレクションのフィールドにマッピングする際に、変数の横に黄色い「レンチ」アイコンが表示されることがあります。この変数の横にある「レンチ」アイコンは、その変数にフォールバックを設定する必要があることを示しています。フォールバックの使用方法について詳しく学ぶ。

フローがトリガーされた際に、CMSアイテムをドラフトステータスに設定したり、公開の準備をしたり、ライブアイテムを公開したりすることもできます。公開オプションについて詳しく学ぶ。

CMSアイテムの削除（Delete CMS item）

Delete CMS item ブロックを使用すると、ブロックがトリガーされたときにコレクション内のCMSアイテムを削除することができます。CMSアイテムのIDを使用して削除するか、名前でCMSアイテムを選択して削除できます。

注意：フローの設定を行う前に、CMSコレクションとサンプルアイテムを作成しておいて、Delete CMS item ブロックをコレクションに接続できるようにしておく必要があります。

Update CMS item

Update CMS item ブロックを使用すると、CMSアイテムの基本情報とカスタムフィールドを、CMSアイテムのIDまたはCMSアイテムの名前を使用して、静的な入力またはフローからのダイナミックデータ（例：フォーム送信やブロックの出力データからのトリガーデータ）を使用して更新できます。

注意：フローの設定を行う前に、CMSコレクションとコレクションアイテムを作成しておいて、Update CMS item ブロックをコレクションに接続できるようにしておく必要があります。

Create CMS item ブロックと同様に、フォームデータを直接CMSコレクションの基本情報とカスタムフィールドにマップできます。同じデータタイプ同士のみをマップできます（例：フォームのプレーンテキストフィールドのデータは、CMSのプレーンテキストフィールドにのみマップできます）。サポートされるバインディングには以下が含まれます：

フォームフィールドタイプ

注：現在、CMSではプレーン・テキスト・フィールドからリンク・タイプ・フィールドへのマッピングはサポートしていません。

重要：変数をCMSコレクションのフィールドにマッピングする際に、変数の横に黄色い「レンチ」アイコンが表示されることがあります。この変数名の横にある「レンチ」アイコンは、その変数にフォールバックを設定する必要があることを示しています。フォールバックの使用方法について詳しく学ぶ。

アップデートしているCMSアイテムの現在のステータスを保持したり、ドラフトステータスに設定したり、公開の準備をしたり、ライブアイテムを公開したりすることができます。公開オプションについて詳しく学ぶ。

CMSアイテムの検索（Search for CMS items）

注意： Logicでサポートされていない必須フィールドを含むコレクションは、Search for CMS items ブロックで使用できません。

Search for CMS items ブロックを使用すると、フロー内のデータを使用して、CMSアイテムをCMSアイテムのIDまたは名前で検索することができます。これにより、後でフロー内で返されたCMSアイテムのデータを使用してアクションを実行できます。これは、ユーザーが生成したコンテンツを持つサイトや、リードを収集するマーケティングサイトに役立ちます。

たとえば、料理のレシピを提出できる料理本サイトを作成した場合、フォームの提出からのレシピ名を使用してCMS内でレシピを検索し、Conditional rule ユーティリティブロックと Send email notification ブロックを使用して、その名前の既存のレシピが見つかった場合は提出をサイトのエディターに送信します。その後、エディターは同一のレシピを削除または統合できます。

重要：Search for CMS itemsブロックの後にConditional rule utilityブロックが続く場合、アイテムが見つからないと、フローはSearch for CMS itemsブロックで停止し、それ以降のアクションは実行されません。

Make HTTP request

Make HTTP request ブロックは、Webflow Logicと外部のテックスタック（たとえば、Mailchimp、Airtableなど）を接続し、RESTful APIエンドポイントに対して自動的にHTTPリクエストを行うことができるブロックです。その後、応答データを使用してフロー内でアクションを実行できます。

ユーザーの招待（Invite user）

Invite user ブロックを使用すると、ユーザーをユーザーアカウントサイトに自動的に招待し、アクセスグループに割り当てることができます。たとえば、リードジェネレーションフォームに接続されたフォーム送信トリガーを使用して、サイトの訪問者がユーザーアカウントを希望することを示すことができます。

注意： Invite user ブロックは、ユーザーアカウントが有効なサイトでのみ使用できます。

ユーザーアカウントの削除（Delete user account）

Delete user account ブロックを使用すると、ユーザーIDまたはユーザーのメールアドレスを使用して、ユーザーアカウントサイトからユーザーを自動的に削除できます。また、サイト上の既存のユーザーを選択することもできます。

注意： Delete user account ブロックは、ユーザーアカウントが有効なサイトでのみ使用できます。

ユーザーアカウントを更新（Update user account）

Update user account ブロックを使用すると、ユーザーのIDまたはユーザーのメールアドレスを使用して、ユーザーの設定（たとえば、マーケティングコミュニケーション用）やアクセスグループを更新できます。また、サイト上の既存のユーザーを選択して、そのユーザーの設定を更新することもできます。

注意： Update user account ブロックは、ユーザーアカウントが有効なサイトでのみ使用できます。ユーザーアカウントについて詳しく学ぶ。

ユーティリティ（Utilities）

Conditional rule ユーティリティブロックを使用すると、次に何が起こるかを決定する条件を設定できます。条件AならばアクションBを実行し、条件CならばアクションDを実行する、といった具体的なルールを設定できます。

つまり、条件を作成し、条件が満たされた場合に実行されるアクションを設定できます（これらのアクションは「true」ブランチで実行されます）。また、条件が満たされない場合に実行されるアクションも設定できます（これらのアクションは「false」ブランチで実行されます）。これにより、トリガー設定や出力データに基づいて、メール通知、HTTPリクエスト、CMSコレクションアイテムの管理などを自動化できます。

たとえば、フォーム送信トリガーの後に Conditional rule ユーティリティブロックを配置すると、フォーム送信からの出力データ（例：名前、メールアドレスなど）に基づいて条件付きのルールを作成できます。この例を詳しく説明すると、フォームを提出した人が「Mike Wazowski」という名前であれば、フローの一部を実行するルールを作成できます。したがって、Mike Wazowskiがフォームを送信した場合、フローの一部が実行されますが、それ以外の誰か（Mike Wazowski以外の名前）がフォームを送信した場合は、フローの異なる部分が実行されます。

注意：「true」ブランチと「false」ブランチの両方にアクションを設定する必要はありません。たとえば、「name」フィールドが設定された状態でフォームが送信された場合にCMSアイテムを作成したい場合、Create CMS item アクションを「true」ブランチにのみ含めます。「false」ブランチ（「name」フィールドに値が含まれていない状態でフォームが送信された場合に実行されるブランチ）にはアクションがないため、何も実行されません。

フロー内のすべての前のブロックからの出力データを基に、条件付きのルールを作成できます。たとえば、フォームの送信が Search for CMS items アクションブロックをトリガーとするフローを作成した場合、Conditional rule ユーティリティブロックは、フォームの送信データとCMSアイテムのデータの両方を使用できます。

これは、ユーザーが生成するコンテンツを持つサイトやリードを収集するマーケティングサイトに役立ちます。たとえば、レシピを提出できる料理本のサイトでは、料理のタイプに基づいてレシピの提出を異なるコレクション（たとえば「朝食」、「前菜」、「デザート」）に送信するための条件付きのルールを作成できます。また、セールスリードをキャプチャするマーケティングサイトでは、フォームの送信から企業名を使用してCMS内の既存のリードを検索し、企業名に基づいてリードを作成または更新することができます。

Conditional rule ユーティリティブロックを設定するには、ブロックを選択してから、Conditional rule settings > Condition に移動します。Select field ドロップダウンからフィールドを選択し、次にSelect logic ドロップダウンから論理のタイプ（例：Is set、Is empty、Ends with など）を選択します。

以下のフィールドタイプが Select field ドロップダウンで使用できます：

Plain text
Email
Phone
Number
Text area
Checkbox
Select
Radio button

もしも選択した論理のタイプ（「Equals」、「Contains」、「Starts with」などとも呼ばれる「オペレーター」）が比較を必要とするものである場合、Enter text フィールドが表示されます。ここでは、目的のテキストを入力するか、フィールド内の紫色の「dot」アイコンをクリックして変数を追加する必要があります。利用可能なオペレーターについて詳しく学ぶ。

このフィールドでアクセスできる変数は、最初のフィールド（すなわちデータ型）と選んだ論理のタイプに依存します。上記で述べたマーケティングサイトの例では、フォーム内の「企業名」がCMSアイテム内の「名前」と等しいかどうか、または含まれているかどうかを確認するための比較を作成します。この例では、変数は「企業名」と「名前」です。

重要: すべての比較は大文字と小文字を区別します。たとえば、条件が「名前が G を含む」場合、「Grímur」はtrueを返しますが、「grímur」はfalseを返します。

いつでも、Condition ドロップダウンをクリックして、Unlink をクリックすることで、フィールドやロジックのリンクを解除することができます。

利用可能なオペレーター

それでは、各データ型に対して利用可能なロジックのタイプ、または「オペレーター」を見てみましょう。

Data type

Plain text

Is set
Is not set
Equals
Does not equal
Contains
Does not contain
Starts with
Does not start with
Ends with
Does not end with

Number

Is set
Is not set
Equals
Does not equal
Is greater than
Is less than
Is greater than or equal
Is less than or equal

Option

Is set
Is not set
Equals
Does not equal
Contains
Does not contain

Boolean (also called “Switch” in the Webflow Designer)

Is true
Is false

Phone

Is set
Is not set
Equals
Does not equal
Contains
Does not contain

Is set
Is not set
Equals
Does not equal
Contains
Does not contain

Link

Is set
Is not set
Contains
Does not contain
Starts with
Does not start with
Ends with
Does not end with

Color

Equals
Does not equal

Video link

Contains
Does not contain
Starts with
Does not start with
Ends with
Does not end with

Select

Equals

Radio button

Equals

注意: Is set オペレーターは、変数（例：フォームの入力値）が存在するかどうかをテストします。テキストが空白文字（スペース）だけを含む場合、「false」を返します。Is empty オペレーターは、変数（例：フォームの入力値）が空でないデータを含むかどうかをテストします。変数にデータが含まれている場合、または変数に空白文字（スペース）だけが含まれている場合、「true」を返します。言い換えれば、サイトの訪問者が入力フィールド（例：「名前」フィールド）にスペースだけを入力してフォームを送信した場合、Is empty を使用した入力フィールドの条件付きルールは「true」を返し、フローの「true」ブランチが実行されます。一方、Is set を使用した入力フィールドの条件付きルールは「false」を返し、フローの「false」ブランチが実行されます。

Fallback の使用方法

Fallback は、変数が利用できない場合に代わりに使用されるデフォルトの値です。Incoming webhook トリガーからのデータや、必須ではないフォーム送信トリガーからのデータを扱う際には、Fallback を設定する必要があります。変数の横に黄色い「wrench」アイコンが表示されると、その変数には Fallback が必要です。

たとえば、フォーム送信によってトリガーされるデータを使用して CMS アイテムを作成するフローを作成したとします。CMS アイテムの名前をフォームの「名前」フィールドのデータを使用して設定することを目指していますが、フォームの「名前」フィールドは必須ではありません。フォーム送信で「名前」フィールドが空白のままだった場合、設定した Fallback が代わりに CMS アイテムの名前に使用されます。たとえば、「名前は提供されていません」という Fallback を設定し、サイトの訪問者が「名前」フォームフィールドを入力せずにフォームを送信した場合、CMS アイテムの名前は「名前は提供されていません」となります。

変数に Fallback を設定する方法:

変数名の横にある黄色い「wrench」アイコンをクリックします。
Fallback の値を入力するか、他の変数を Fallback として使用するために紫色の「点」アイコンをクリックします。

Fallback を変数から削除する方法:

フォールバック値を削除したい変数をクリックします。
Fallback フィールドからフォールバック値を削除します。

フローのテスト方法

フローを公開する前に、ブロックが正しく設定され、フローがスムーズに実行されることを確認するために、フローをテストすることが最適な方法です。これは、フローの問題をデバッグする際にも役立ちます。

フローをテストするには、Flow editor の右上隅にある Test flow をクリックします。これにより、フローに接続されたトリガーを実行するためのサンプルデータを入力できるモーダルメニューウィンドウが開きます（たとえば、Form submission トリガーがある場合、サンプルフォームを記入します）。サンプルデータを入力したら、Run test をクリックしてテストフローを実行します。テストが実行された後、テスト結果がモーダルメニューウィンドウに表示されます。

Make HTTP request ブロックも、他のフローの部分とは別にテストすることができます。Make HTTP request ブロックを右クリックし、Test this action を選択するか、キャンバス上の Make HTTP request ブロックを選択して Block settings 内の Run test to complete setup をクリックします。これにより、Block settings で使用した値のサンプルデータを入力できるモーダルメニューウィンドウが開きます。

サンプルデータを入力したら、Run test をクリックしてこのブロックのテストを実行します。テストが実行された後、テスト結果がモーダルメニューウィンドウに表示されます。その後、テストの応答を使用して残りのフローをテストするために Apply data をクリックできます。

実行履歴

実行履歴を使用すると、フローの過去の成功した実行と失敗した実行のログを表示できます。実行履歴にアクセスするには、Flow editor > History タブを開きます。実行履歴内の任意のタイムスタンプをクリックすると、そのフローの実行をトリガーした入力データが表示されます。

フローを公開する方法

フローを公開するプロセスは、フローを開始するトリガー（つまり、Form submisionまたはincoming ****Webhook）によって異なります。フローがサイト上の何かと対話しない場合、サイトの公開とは別にフローの公開を管理できます（これは、フォームの送信トリガーを持つフローには適用されません。これらはサイト上のフォームに依存しています）。

注意：フローを単一のドメインに公開することはできません。サイトに接続されたすべてのドメインにフローを公開する必要があります。

重要：フローにCMSアイテムに影響を与えるブロック（例：Create CMS item、Delete CMS itemなど）が含まれ、CMSコレクションスキーマを変更（例：コレクションフィールドの追加または削除）した場合、フローを再構成し、公開の準備をする必要があります。

フォームの送信トリガーを公開する

フォームの送信トリガーを使用してフローを公開するには、まず Flow editor 内の Form ドロップダウンからフローをトリガーするフォームを選択する必要があります。次に、次回のフルサイトの公開時にフローを公開するために Publish をクリックし、その後 Stage flow for publish をクリックします。

重要：フォームの変更（例：フィールドの追加または削除）を行った場合、変更後のフォームがフローで使用できるようにするために、サイトを再度公開する必要があります。

また、フローを即座にライブサイトから非公開にするには、Publish をクリックしてから Unpublish flow をクリックします。

もしあなたのフローのいずれかに未解決の問題がある状態でサイトを公開しようとすると、未解決の問題を抱えたフローのリストが表示されるアラートモーダルが表示されます。それらの問題を解決せずにサイトを公開し続けると、未解決の問題を抱えたフローは無効になります。

受信 Webhook トリガーを公開する

フォームの送信トリガーを使用するフローとは異なり、受信 Webhook トリガーを使用するフローを公開する必要はありません。

受信 Webhook トリガーを使用するフローを公開するための2つのオプションがあります。

フローを即座にライブサイトに公開する場合は、Publish をクリックしてから Publish flow now をクリックします
フローを次回のフルサイト公開時に公開する場合は、Publish をクリックしてから Stage flow for publish をクリックします

Flow editor 内でいつでも Publish flow now をクリックして、フローへの新しい変更を即座にライブにプッシュすることができます。フローに対する将来の変更は、Publish flow now をクリックするまでライブサ

フローを即座にライブサイトから非公開にするには、Publish をクリックしてから Unpublish flow をクリックします。

サイトを公開しようとした際に、いずれかのフローに未解決の問題がある場合、未解決の問題を抱えたフローのリストが表示されるアラートモーダルが表示されます。これらの問題を解決せずにサイトを公開し続けると、未解決の問題を抱えたフローは無効になります。

フローの名前変更、複製、削除方法

フローの名前を変更したり、複製したり、削除したりするオプションは、フロー名の隣にあるドロップダウン矢印メニュー内にあります。

フローの名前を変更するには、Flow settings.内のFlow nameを置き換えることもできます。

注意: 個々のブロックの名前を変更するには、ブロックの設定でブロック名を入力または置き換えることができます。個々のブロックをフローから削除するには、ブロック上で右クリックして「ブロックの削除」をクリックするか、ブロックを選択してキーボードの「Delete」キーを押します。現時点では個々のブロックを複製することはできません。

FAQ とトラブルシューティングのヒント

1つのサイトにいくつのフローを持つことができますか？

パフォーマンスの問題を防ぐために、1つのサイトには20個のフローの制限があります。1つのサイトで20個以上のフローを作成しようとすると、まずフローを1つ削除するよう促されます。

1つのフローにいくつの条件ルールやアクションブロックを使用できますか？

1つのフローには最大で50個のブロックを追加できます。これには条件ブロックも含まれます。ブロックの数が50個に達すると、「最大数の50個のブロックに到達しました」というエラーメッセージが表示されます。

Logicは私のサイトやワークスペースのプランに含まれていますか？

Logicを使用するにはサイトやワークスペースのプランは必要ありませんが、使用制限を増やしたり、作成できるフローの数を増やすにはサイトやワークスペースのプランが必要な場合があります。Logicの使用制限に関する情報は、プランと価格ページをチェックしてみてください。

どのワークスペースの役割がフローの構築と管理の権限を持っていますか？

すべてのワークスペースの役割はフローの構築と管理の権限を持っています。ただし、サイトレベルの Can designまたはCan design (Limited) の役割を持つワークスペースメンバーは、フルサイトを公開できないため、これらのワークスペースメンバーはサイト上の要素と対話するフロー（例：フォーム送信トリガーを使用するフロー）を公開する際に他のメンバーからの支援が必要かもしれません。ワークスペースの役割とパーミッションについてはこちら

助けてください！フローに変更を適用できません！

フォーム送信トリガーを使用している場合、フローをフォームに接続するかフォームに変更を加えた後にサイトを公開したことを確認してください。サイトを公開した後、次回のフルサイトの公開時に変更をフローに適用するためにStage for publishをクリックできます。

これをすでに行っており、それでもフローに変更を適用できない場合、すべてのブロック設定が適切に構成されていることを確認し、フローのすべてのブロックに緑色のチェックマークアイコンが表示されていることを確認してください。フローのどこかに黄色いレンチアイコンが表示されている場合、これはブロックの設定がまだ構成されていないことを示しています。

フローで使用しているフォームフィールドが変更されるとどうなりますか？

公開済みのフローはもはや機能しません。これは、フォームフィールドが削除された、追加された、または名前が変更された場合に発生します。フローを再構成し、フローをステージングして公開する必要があります。

以前は動作していたフローですが、今はフローのトリガーに感嘆符が表示されます。

もしフォームトリガーを使用しており、フォームに変更を加えた場合（例：フォーム名の変更、フォームフィールドの追加や削除など）、フローのトリガーをリセットして再構成する必要があります。これを行うには、Flow editorでトリガーを選択し、Trigger settingsに移動し、「Reset the form trigger」をクリックしてください。

アクションブロックがうまく機能していない場合

もしアクションブロックが正しく動作しない場合は、まずブロックの設定が適切に行われていることを再確認してください。特に、Make HTTP requestブロックの場合は、HTTPリクエストとブロックの設定が正しく構造化されていることを確認してください。すべてのブロックの設定が正しく行われている場合は、サイトを再公開してフローの変更を適用してみてください。

もしサイトの再公開が問題を解決しない場合は、画面録画を行い、Webflow Logicのバグとフィードバックフォームに問題を提出してください。提出時には、あなたのフローIDも含めるようにしてください。

共同作業者が、送信メール通知ブロックに追加された後にサイトまたはワークスペースから削除された場合、どうなりますか？

以前の共同作業者は、もはや送信メール通知ブロックからメールを受け取らなくなります。ただし、送信メール通知ブロックの設定内の共同作業者リストからは自動的に削除されません。削除する必要があります。

サイトのコンテンツやデザインをロジックを使って変更できますか？

「Create CMS item」ブロックと「Update CMS item」ブロックは、Create asをLiveに設定した場合、サイトのコンテンツを変更するために使用できます。ただし、サイトはCMSコンテンツのライブ変更を反映するためにリフレッシュが必要です。

ただし、これらのCMS関連のブロックを除外して、現時点ではコンテンツやデザインを変更するためにロジックを使用することはできません。

サイトをエクスポートしてもロジックは機能しますか？

ロジックフロー（CMSやEコマースのコンテンツも含む）はエクスポートされたコードに含まれません。ロジックは正常に機能するためにはホスティングが必要です。

他のワークスペースのメンバーは、私が追加した認証情報（第三者APIキー、ユーザー名、パスワードなど）を見ることができますか？

ワークスペースのメンバーは認証情報を見ることができ、管理し、使用することができます。ただし、認証情報が作成されると、その認証情報の元の作成者であるとしても、WebflowのUI上では認証情報の実際の値を誰も見ることができません。つまり、ワークスペースのメンバーは認証情報のユーザー定義名を見ることはできますが、実際のトークンやキーにはアクセスできません。

Webflowは認証情報をどのように保存し、処理しますか？

認証情報は常に安全に保存され、転送中には常に暗号化され、静止時にも暗号化されます。認証情報が作成されると、その認証情報の元の作成者であるとしても、WebflowのUI上では認証情報の実際の値を誰も見ることができません。作成された認証情報のユーザー定義名のみを表示できます。

Webflowは認証情報を安全な方法で保存しますが、Webflowはロジックフローを使用してその認証情報をサーバーや第三者サービスに送信する際の制御を持っていません。

サイトをクローンまたは転送すると、認証情報はどうなりますか？

サイトをクローンまたは転送する際に認証情報は保持されません。フローで使用される認証情報は、サイトがクローンまたは転送された後に再作成する必要があります。

ショーケースからサイトをクローンすると、フローも含まれますか？クローン可能なサイトを通じて他とフローを共有できますか？

はい。サイトをクローンすることはサイトを複製することと同等です。サイトに関連するすべての要素、フローも含まれますが、認証情報は除外されます。サイトがクローンされた後、フローで使用される認証情報は再作成する必要があります。

サイトを転送する際、フローも一緒に転送されますか？

はい。サイトに関連するすべての要素、フローも転送されますが、認証情報は除外されます。サイトが転送された後、フローで使用される認証情報は再作成する必要があります。

バックアップからサイトを復元すると、フローはどうなりますか？復元されるのか、変更されないのか？

バックアップを復元すると、そのバックアップが作成された時点でのフローの状態に復元されます。ただし、現在のサイトとバックアップ間でフォームやCMSスキーマが異なる場合、バックアップの復元によって公開されたフローが壊れる可能性があります。