Webflowロジックサマリー

Webflow Logic を利用すると、潜在的な販売見込み客を収集して誘導したり、顧客と交流したり、Web サイトのコンテンツを監視したりする自動化されたシーケンス (「フロー」と呼ばれる) を構築して実行できます。これらはすべて、Webflow Designer インターフェイスを通じて実行できます。 

このチュートリアルでは、次の内容を取り上げます。

1. ロジックへのアクセス
2. フローの作成と整理
3. フォールバックの実装
4. フローのテスト
5. 出版フロー
6. フローの名前変更、複製、削除
7. よくある質問と問題解決の提案

ロジックへのアクセス

Webflowロジックを開始するには、 論理 左サイドバーにあるアイコンをクリックすると、 ロジックパネルそこから、 流れ タブをクリックして、フローの一般的な詳細（フロー名、トリガー、トリガーソース、ステータスなど）を確認し、 フローエディタ フローを構築、管理、テストします。

フローの作成と整理

フローは、トリガー、アクション、条件という3つの主要コンポーネントで構成されています。新しいフローを作成するには、 ロジックパネル > 流れ タブを押して 新しい流れ 入力する フローエディタ.

の中に フロー設定 セクションで、割り当てる タイトル そして 説明 新しいフローを明確にし、区別するために、 フローIDトラブルシューティングの目的でフローの識別子として機能します。

トリガーを選択してフローの構築を進め、アクションとツールを接続スポットにドラッグアンドドロップします。 フローエディタ キャンバス。

不可欠： フローを構築している間、黄色の「レンチ”アイコンは、設定が完了するまで各ブロック上に表示されます。設定が完了すると、黄色の「レンチ” が緑色の “ に置き換えられますチェックマーク”アイコンをクリックします。

注意点: 出発 フローエディタ 保存しない場合は、フローは下書きモードのままになり、変更内容が保持されます。

フロー内のブロックを別の接続ポイントにドラッグアンドドロップすることで、ブロックを並べ替えることができます。ブロックは、右クリックして選択することでフローから削除することもできます。 ブロックを削除、または選択して押す 消去 キーボードで。

トリガー

各フローはトリガーによって開始されます。トリガーとは、フローを開始するサイト内 (フォームの送信など) または外部 (Webhook イベントなど) で発生するイベントです。

フローにトリガーを統合するには、 このフローを開始するトリガーを選択してください 希望するトリガーを選択します。トリガーの選択肢は 2 つあります。

• フォーム送信 – Webflowサイトでフォームを送信すると有効になります
• 受信ウェブフック – 外部プラットフォームのイベントによってトリガーされる

リマインダー： 各フローにはトリガーを 1 つだけ設定できます。 

トリガーを追加したら、キャンバス上のトリガーブロックを選択し、 トリガー名、トリガーの種類（フォーム送信や着信 Webhook など）に基づいてトリガー設定を構成します。

フローからトリガーを置き換えたり削除したりするには、トリガーを右クリックして トリガーを削除、または選択して 消去 キーボードで。

トリガーの出力（つまり、後続のブロックと共有されるデータ）を トリガー設定 > 出力 タブ。

トリガーの後には、アクション（電子メール通知の送信、CMS アイテムの作成、ユーザーの招待など）を実行したり、ツールを使用して条件を確立したりできます。

フォーム送信

フォーム送信トリガーを使用する場合は、サイトにフォームを追加して開始します。フローのトリガーを指定されたフォームに接続し、ユーザーがフォームを送信したときにフローが実行されるようにします。 

重要： 各フォームは 1 つのフローのトリガーとしてのみ機能します。複数のロジック フローに使用することはできません。 

フォームをフローにリンクするには:

1. 開く フローエディタ
2. を選択 フォーム送信トリガー ブロックして表示する トリガー設定
3. ドロップダウンメニューからフォームを選択してください

デザイナーキャンバスからフォーム送信トリガーを組み込むには、フォームを選択し、 要素設定パネル > フォーム設定 > ソース、 変化 ソース に 論理、どちらかを選択してください 新しいフローを追加 または フローを閲覧する フォームを新規または既存のフローにリンクします。 

フォーム送信トリガーからフォームを切り離すには、 フローエディタ、…そして次に進む 設定を有効にする > 形状 ドロップダウンをタップして リンク解除フォーム. 

重要： 必要に応じて、Web サイトでスパム フィルタリングを有効にして、フォーム入力にスパムが含まれていないか検査することができます。スパム フィルタリングの詳細については、こちらをご覧ください。 

ウェブフックの受信

受信 Webhook スイッチを使用すると、外部アプリケーション (Airtable、Make、Twilio など) からフローに JSON 形式でリアルタイム データを転送できます。基本的に、受信 Webhook スイッチにより、外部アプリがフローと通信できるようになります。 

受信ウェブフックスイッチを使用するには、 ウェブフックURL スイッチ設定から、この Webhook にリクエストを送信するサードパーティ アプリケーションに挿入します。たとえば、Mailchimp から Webhook を送信して、ロジック フローを開始できます。 

重要： Webhook スイッチを受信するには、Webhook と通信するために外部のサードパーティ ユーティリティを使用する必要があります。サポートや機能に関するお問い合わせは、サードパーティ ユーティリティに直接お問い合わせください。 

活動 

アクティビティブロック フローで実行したい内容を指定できます。オプションで入力データを受け取り、推論セグメントを実行し、常に出力データ (つまり、後続のブロックと共有される情報) を生成することができます。 

出力データ（つまり、ブロックがフロー内の後続のブロックと共有する情報）を精査することができます。 アクティビティブロック で ブロック設定 > 出力 タブ。

入手可能なものを探ってみましょう アクティビティブロック: 

• メールアラートを配信する
• CMS要素を生成する
• CMS要素を排除
• CMS要素の変更
• CMS要素を探す
• HTTPリクエストを開始する
• ユーザーを召喚
• ユーザー記録を消去
• ユーザーレコードを修正する

メールアラートを配信する 

の メールアラートを配信する ブロックにより、フローがトリガーされたときに、サイト上のコンテンツ編集者またはワークスペースの個人にカスタム電子メールアラートを送信することが許可されます。 

ブロックを選択して フローエディタ に移動して メールアラートブロック設定を配布するその後、 転送先 フィールドでアクセス可能な共同作業者のプールから特定の共同作業者を選択するか、 すべての協力者 リスト上のすべての投稿者に電子メールアラートを送信します。 

重要： ワークスペースのメンバーではない個人に電子メール アラートを送信する場合は、そのユーザーをコンテンツ エディターとしてサイトに組み込むか、Initiate HTTP request ブロックを使用してデータを外部の電子メール サービスに転送する必要があります。コンテンツ エディターをサイトに招待する方法の詳細については、こちらをご覧ください。

トリガーからのさまざまなデータを使用して、電子メールの件名とメッセージをパーソナライズできます。件名とメッセージのフィールドでは、次のデータ タイプを使用できます。 

• 率直
• 電子メール
• 携帯電話
• 番号
• テキストゾーン
• チェックマーク
• タイムスタンプ

メール通知の受信を停止するには、「ごみ名前の横に「 」アイコンが表示されます。 

CMS要素を生成する 

の CMS要素を生成する ブロックを使用すると、ブロックがトリガーされたときに、コンパイル内に新しい CMS 要素を作成できます。ブロック設定には、選択したコンパイル内に存在するフィールドが表示されます。 

重要： フローを構成する前にCMSコンパイルをセットアップして、添付できることを確認してください。 CMS要素を生成する コンパイルへのブロック。 

不可欠： CMS にデータを組み込む場合は、プライバシーへの影響に注意してください。たとえば、リードを集めて、そのリードに基づいて CMS 要素を設定すると、それらの項目はサイトマップに含まれ、サイトの読み取り専用プレビュー リンクを持つユーザーなら誰でもそれらを表示できます。サイト訪問者に表示したり、検索エンジンにインデックス付けしたりすべきでない動的ページは、noindex にする必要があります。検索エンジンのインデックス作成を無効にする方法とプライバシーの最適な方法については、こちらをご覧ください。

このブロックを使用すると、固定入力を相関させることができます または フローからの動的データ (フォーム送信からのトリガー データやブロック出力データなど) を CMS コンパイルの基本情報とパーソナライズされたフィールドに直接送信します。 類似のデータの種類のみを相互に関連付けることができます (たとえば、フォームのプレーン テキスト フィールドのデータは、CMS のプレーン テキスト フィールドにのみ関連付けることができます)。 補助バインディングは以下をカバーします。 

述べる： 現在、CMS 内のプレーン テキスト フィールドからリンク タイプのフィールドへのマッピングはサポートされていません。また、カスタム コンポーネントを使用して作成されたフィールドもサポートされていません。

重要な： 黄色の「レンチ”アイコンは、変数をCMSコレクションフィールドにリンクすると、変数の横に表示されます。この“レンチ変数の横にある「 」アイコンは、その変数のフォールバックを定義する必要があることを示しています。フォールバックの使用について詳しくは、こちらをご覧ください。

また、CMS アイテムを下書きステータスに指定したり、公開用にステージングしたり、フローが開始されたときにライブ アイテムを公開したりすることもできます。公開オプションの詳細については、こちらをご覧ください。

CMSアイテムを消去 

の CMSアイテムを削除 ブロックを有効にすると、コレクション内の CMS アイテムを削除できます。CMS アイテム ID で削除することも、名前で CMS アイテムを選択することもできます。 

述べる： フローを構成する前に、CMSコレクションとサンプルアイテムを作成して、接続できることを確認してください。 CMSアイテムを削除 コレクションへのブロック。 

CMSアイテムを修正 

の CMSアイテムの更新 ブロックを使用すると、静的入力を使用して、CMSアイテムIDまたはCMSアイテム名でCMSアイテムの基本情報とカスタムフィールドを変更できます。 または フローからの動的データ (例: フォーム送信からのトリガー データまたはブロック出力データ)。 

述べる： フローを整理する前に、CMSコレクションとコレクションアイテムを生成して、リンクできるようにしてください。 CMSアイテムの更新 コレクションへのブロック。 

同様に CMSアイテムを作成する ブロックを使用すると、フォーム データを CMS コレクションの基本情報とカスタム フィールドに直接関連付けることができます。関連付けることができるのは、同じデータ型だけです (たとえば、フォームのプレーン テキスト フィールドのデータは、CMS のプレーン テキスト フィールドにのみリンクできます)。サポートされているリンクは次のとおりです。 

述べる： 現在、CMS ではプレーンテキスト フィールドからリンク タイプのフィールドへのマッピングはサポートされていません。また、カスタム コンポーネントを使用して作成されたフィールドも推奨されていません。

重要な： 黄色の「レンチ”アイコンは、変数をCMSコレクションフィールドにリンクすると、変数の横に表示されます。この“レンチ変数名の横にある「 」アイコンは、その変数にフォールバックを設定する必要があることを示しています。フォールバックの使用について詳しくは、こちらをご覧ください。

変更中の CMS アイテムの現在のステータスを維持するか、下書きステータスに設定し、公開用にステージングするか、フローが開始されたときにライブ アイテムを公開することができます。公開オプションの詳細については、こちらをご覧ください。

CMSアイテムを探す 

述べる： Logic でサポートされていない必須フィールドを含むコレクションは、CMS アイテムの検索ブロックでは使用できません。

の CMSアイテムを検索 ブロックを使用すると、フローのデータを使用して、CMS アイテム ID または名前で CMS アイテムを検索できます。これにより、フローの後半で取得した CMS アイテムのデータを使用してアクションを実行できます。これは、ユーザー生成コンテンツのあるサイトやリードを集めるマーケティング サイトにとって有利です。 

たとえば、訪問者がレシピを投稿できるcookbookサイトを構築した場合、フォームの投稿からレシピ名を使用してCMSでレシピを検索し、 条件付きルール ユーティリティブロックと メール通知を送信 ブロックの場合、その名前の既存のレシピが見つかった場合は、投稿をサイト編集者に送信します。その後、サイト編集者は同一のレシピを削除/結合できます。

重要な： CMS アイテムの検索ブロックとそれに続く条件ルール ユーティリティ ブロックでアイテムが見つからない場合、フローは CMS アイテムの検索ブロックで停止し、後続のアクションは実行されません。 

HTTPリクエストを行う 

の HTTPリクエストを行う ブロックは、任意の RESTful API エンドポイントへの HTTP リクエストを自動化できるようにすることで、Webflow Logic と外部の技術スタック (Mailchimp、Airtable など) を接続します。その後、フロー内で応答データを使用してアクションを実行できます。 

HTTP リクエストの作成ブロックの詳細をご覧ください。

ユーザーを招待 

の ユーザーを招待 ブロックを使用すると、ユーザーをユーザー アカウント サイトに招待し、アクセス グループに割り当てる操作を自動化できます。このブロックは、たとえば、サイト訪問者がユーザー アカウントの希望を示すことができるリード生成フォームにリンクされたフォーム送信トリガーと組み合わせると、うまく機能します。

述べる： の ユーザーを招待 ブロックは、ユーザー アカウントが有効になっているサイトでのみアクセスできます。ユーザー アカウントの詳細については、こちらをご覧ください。

ユーザーアカウントを削除する 

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

述べる： の ユーザーアカウントを削除する ブロックは、ユーザー アカウントが有効になっているサイトでのみ利用できます。ユーザー アカウントの詳細については、こちらをご覧ください。

ユーザーアカウントの変更 

の ユーザーアカウントを更新する ブロックを使用すると、ユーザーの設定（マーケティング コミュニケーションなど）を変更したり、ユーザー ID またはユーザーの電子メールでグループにアクセスしたりできます。また、サイト上の既存のユーザーを選択して、そのユーザーの設定を調整することもできます。

述べる： の ユーザーアカウントを更新する ブロックは、ユーザー アカウントが有効になっているサイトでのみアクセスできます。ユーザー アカウントの詳細については、こちらをご覧ください。

ツール

の 条件付きルール ユーティリティ ブロックを使用すると、フロー内の後続のアクションを決定する条件を設定できます。条件 A の場合はアクション B を実行し、条件 C の場合はアクション D を実行します。 

本質的には、条件を定式化し、条件が満たされた場合（つまり、アクションは「true」パスで実行される）および条件が満たされなかった場合（つまり、アクションは「false」パスで実行される）に実行されるアクションを指定できます。これにより、フローのトリガー設定または出力データのルールに基づいて、電子メール通知、HTTP リクエスト、CMS コレクション アイテムの管理などを自動化できます。 

例えば、 条件付きルール フォーム送信トリガーの後にユーティリティ ブロックを追加すると、フォーム送信からの出力データ (名前、メール アドレスなど) に基づいて条件付きルールを設定できます。この図をさらに詳しく見ると、Mike Wazowski という名前のユーザーがフォームを送信した場合にフローのセクションをトリガーするルールを設定できます。Mike Wazowski がフォームを送信した場合はフローの特定の部分が実行されますが、他のユーザー (Mike Wazowski 以外の名前) がフォームを送信した場合はフローの別のセグメントが実行されます。 

注記： アクションは「true」と「false」の両方のパスで定義する必要はありません。たとえば、「name」フィールドを指定してフォームが送信されたときにCMSアイテムを生成したい場合は、 CMSアイテムを作成する 「true」パスのアクション。「false」パス（「name」フィールドに値を指定せずにフォームが送信されたときに実行される）にはアクションがなく、アイドル状態のままになります。 

出力データに基づいて条件付きルールを作成することができます。 全て フロー内の先行ブロックを設計します。たとえば、フォームの送信によって CMSアイテムを検索 アクションブロック、あなたの 条件付きルール ユーティリティブロックはフォーム送信からのデータを取り込むことができます そして CMS アイテムからのデータ。 

これは、ユーザー生成コンテンツのある Web サイトやリードを集めるマーケティング サイトにとって有利です。たとえば、訪問者がレシピを投稿できる料理 Web サイトでは、料理の種類に基づいてレシピの投稿をさまざまなコレクション (「朝食」、「前菜」、「デザート」など) にリダイレクトする条件付きルールを設定できます。または、セールス リードを獲得するマーケティング Web サイトでは、フォームの投稿から会社名を使用して CMS で既存のリードを検索し、会社名に基づいて CMS でリードを作成または更新できます。 

設定するには 条件付きルール ユーティリティブロック、ブロックを選択して、 条件付きルール設定 > 状態. からフィールドを選択してください フィールドを選択 ドロップダウンからロジックの種類を選択します ロジックを選択 ドロップダウン (例: 設定されている、空である、次で終わる、など)。 

以下のフィールドタイプは、 フィールドを選択 落ちる：

• プレーンテキスト
• Eメール
• 電話
• 番号
• テキストエリア
• チェックkbox
• 選択する
• ラジオボタン

比較を必要とするロジック（「演算子」とも呼ばれます）を選択した場合（例：等しい、含む、始まるなど）、 テキストを入力 フィールドが表示されます。ここで、希望するテキストを入力するか、紫色の「ドットフィールドに「 」アイコンが表示されます。Logic で使用可能な演算子の詳細をご覧ください。

このフィールドでアクセスできる変数は、初期フィールド (つまり、データ タイプ) と選択したロジックのタイプによって異なります。前述のマーケティング サイトの例では、フォームの「会社名」が CMS 項目の「名前」と一致するか、または含まれているかどうかを確認するために比較を行います。このコンテキストの変数は、「会社名」と「名前」です。 

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

フィールドやロジックをいつでも切断するには、 状態 ドロップダウンから選択 リンクを解除. 

利用可能な演算子 

各データ型で利用可能なロジックの種類、つまり「演算子」を見てみましょう。 

観察： の 設定されています 演算子は変数（フォーム入力値など）が存在するかどうかをチェックします。テキストが空白のみで構成されている場合は「false」を返します。 空です 演算子は、変数（フォームの入力値など）に空でないデータが含まれているかどうかを検証します。変数にデータが含まれているか、空白文字のみが含まれている場合は「true」を返します。訪問者が入力フィールド（「名前」フィールドなど）にスペースのみを含むフォームを送信した場合、 空です 入力フィールドの条件は「true」を返し、フローの「true」ブランチを実行しますが、 設定されています 「false」を返し、フローの「false」ブランチをアクティブにします。

フォールバックの採用

フォールバックは、変数にアクセスできない場合に変数の代わりに使用されるデフォルト値です。フォールバックは、フォーム フィールドの入力が必須ではない受信 Webhook トリガーまたはフォーム送信トリガーからのデータを処理するときに必要です。変数の横にある黄色の「レンチ」記号は、フォールバックが必要であることを示します。

プロセスをトリガーするフォーム送信のデータを使用して CMS アイテムを生成するプログラムを考案したとします。目標は、フォームの「名前」フィールドのデータに基づいて CMS アイテムに名前を付けることですが、これは必須ではありません。フォーム送信で「名前」フィールドが空のままの場合、指定されたフォールバックを使用して CMS アイテムに名前を付けます。たとえば、フォールバックを「名前が指定されていません」に設定し、訪問者が「名前」を入力せずにフォームを送信すると、CMS アイテムの名前は「名前が指定されていません」になります。

変数のフォールバックを設定するには: 

1. 変数名の横にある黄色の「レンチ」記号をタップします
2. フォールバック値を入力するか、紫色の「ドット」記号をクリックして別の変数をフォールバックとして選択します。

変数のフォールバックを排除するには:

1. 除外するフォールバックを意図した変数を選択します
2. フォールバック値を消去する 後退する 分野

フローを評価する方法

ブロックの適切な構成を確認し、フローがスムーズに実行されるようにするには、フローをリリースする前にフローを評価することが賢明です。この方法は、フロー関連の問題のトラブルシューティングにも役立ちます。

フローを評価するには、 テスト流れ 右上隅の フローエディタモーダルメニューが開き、接続されたトリガーのサンプルデータを入力できます。データを入力したら、 テストを実行する テストフローを開始します。テスト結果は、テスト完了後にモーダル メニューに表示されます。

個別にテストできます HTTPリクエストを行う メインフローの外側のブロックを右クリックします HTTPリクエストを行う ブロックして選択 このアクションをテストする、またはキャンバス上のブロックを選択してタップします テストを実行するセットアップを完了するには ブロック設定で、使用される値のサンプル データを入力するためのモーダル メニューが表示されます。 

データ入力後、クリック テストを実行する このブロックのテストを実行します。結果はテスト完了後のモーダルメニューに表示されます。 データの適用 テスト応答を利用してフローの残りの部分を評価します。

操作履歴

操作履歴には、フローの成功と失敗の両方の過去の実行の結果を詳細に示すログが表示されます。操作履歴にアクセスするには、 フローエディタ > 歴史 タブ。操作履歴の任意のタイムスタンプをクリックすると、その特定のフロー実行をトリガーした入力データが表示されます。

フローを完了するための手順

フローの終了手順は、フローを開始するために使用されたトリガー (フォームの送信や着信 Webhook など) によって異なります。フローがサイト要素とやり取りしない場合は、サイトの公開とは別にフローの終了を管理できます (サイト フォームに依存するため、フォームの送信によってトリガーされるフローは除きます)。

重要： フローを単一のドメインに公開することは現実的ではありません。フローは、サイトに接続されているすべてのドメインに公開する必要があります。

不可欠： フロー内に CMS アイテムに影響するブロック (CMS アイテムの作成、CMS アイテムの削除など) が含まれており、CMS コレクション スキーマを変更する場合 (コレクション フィールドの追加または削除など)、フローを再構成して公開用にステージングする必要があります。

フォーム送信フローの完了

フォーム送信トリガーを利用してフローを完了するには、まず、 形状 ドロップダウンの フローエディタ次回のフルサイトリリース時にフローを公開するには、 公開、 それから 公開のステージフロー.

不可欠： フォーム送信トリガーにリンクされたフォームに変更が加えられた場合 (フィールドの追加や削除など)、修正されたフォームがフローで使用可能であることを保証するために、サイト公開を再発行することが必須です。

をタップしてライブサイトからフローをすぐに撤回することもできます。 公開 その後 非公開フロー.

フローに未解決の問題がある状態でサイトを公開しようとすると、未解決の問題が発生しているフローをリストした警告モーダルが表示されます。問題に対処せずにサイトを公開すると、未解決の問題があるフローは非アクティブ化されます。

Publishea 新しい着信ウェブフックのメカニズム

フォーム送信トリガーを利用する手順とは異なり、新しい受信 Webhook トリガーを利用する手順では、必ずしもサイトの公開は必要ありません。 

新しい受信 Webhook トリガーを使用する手順を配布するには、次の 2 つの方法があります。 

• アクティブなサイトですぐに手続きを実行したい場合は、 リリース その後 今すぐ手順を展開
• 今後のフルサイトリリースで手順を公開する予定の場合は、 リリース その後 リリースの手続きを手配する

あなたは関与することができます 今すぐ手順を展開 の中に 手順エディタ いつでも、手順に新しい変更をライブで反映させることができます。毎回サイト全体を起動する必要はありません。手順に実装したその後の変更は、タップするまでアクティブサイトに反映されません。 今すぐ手順を展開.

クリックすることで、アクティブなサイトから手順を即座に撤回することもできます。 リリース その後 手順の削除.

いずれかの手順に保留中の問題がある状態でサイトを公開しようとすると、未解決の問題のある手順の登録を示す警告ダイアログ ボックスが表示されます。問題を解決せずにサイトの公開を続行すると、保留中の問題がある手順はすべて非アクティブになります。

手順の変更、複製、削除に関するヒント

手順のタイトルの隣にあるドロップダウン矢印メニューで、手順を変更、複製、および消去するための代替手段を正確に指定できます。

同様に、以下の文を置き換えることで手順を変更することもできます。 手順タイトル で 手順設定. 

注意: 個々のブロックの名前を変更するには、 ブロックタイトル で ブロック設定手順から個々のブロックを削除するには、ブロックを右クリックして ブロックを削除、またはブロックをハイライトして 消去 キーボードで入力します。現在のところ、個々のブロックを複製することはできません。 

よくある質問と問題解決のヒント

私のサイトで許可される手順の最大数はいくつですか? 

パフォーマンスの低下を回避するために、サイトごとに 20 個のプロシージャの上限が設けられています。サイトに 20 個を超えるプロシージャを設定しようとすると、最初にプロシージャを削除するように求められます。 

単一の手順で使用できる条件付きディレクティブ/アクション ブロックの数はいくつですか? 

単一のプロシージャに最大 50 個のブロックを挿入できます。これには条件ブロックが含まれます。しきい値に達すると、「最大 50 個のブロックに達しました」というエラー メッセージが表示されます。

私のサイト/ワークスペースの取り決めには、Reasoning が含まれていますか?  

Reasoning を使用するために Web サイトまたは Workspace プランを所有する必要はありませんが、使用制限や作成できるプロセスの数を増やすには、Web サイトまたは Workspace プランが必要になる場合があります。 Reasoningの使用制限に関する詳細は、プランと価格のページをご覧ください。. 

どの Workspace 機能に、手順を構築および監視する権限がありますか? 

すべてのワークスペース機能には、手順の構築と管理の権限があります。サイトレベルの権限を持つワークスペースメンバーは、 デザインできる または 缶デザイン（限定） ロールではサイト全体を公開できないため、これらのワークスペース メンバーは、サイト上の要素とやり取りする手順 (フォーム送信トリガーを使用する手順など) を公開するために他のメンバーの支援が必要になる場合があります。ワークスペースの機能と権限の詳細については、こちらをご覧ください。 

サポートが必要です! 手順の変更を実行できません! 

フォーム送信トリガーを使用している場合は、フォームに手順をリンクした後、またはフォームに変更を加えた後にサイトを公開していることを確認してください。サイトを公開したら、 リリースの手配 次回のサイト全体のリリースで手順の変更を実装します。 

すでにこれを完了していても、手順の変更を実行できない場合は、すべてのブロック設定が適切に構成され、緑色の「チェックマーク”アイコンは、手順内のすべてのブロックに表示されます。黄色の「レンチ” アイコンが手順のどこかに表示された場合は、ブロック設定をまだ構成する必要があることを意味します。

手順で使用されるフォーム フィールドが変更されると何が起こりますか? 

ライブ プロセスは機能しなくなります。フォーム フィールドが削除、追加、または名前変更された場合、この問題が発生します。ライブ プロセスを修正するには、プロセスを再構成し、プロセスをリリース用に準備し、サイトを公開する必要があります。

以前は手順が動作していましたが、現在は手順トリガーに感嘆符が表示されています。 

フォームトリガーを使用していて、フォームを変更した場合（フォームタイトルの変更、フォームフィールドの追加または削除など）、フォームトリガーをリセットして手順を再設定する必要があります。これを行うには、 手順エディタ、 案内する トリガー設定をタップします フォームトリガーをリセットする.

アクション ブロックが正しく機能しません。 

ブロック設定が適切に構成されていることを再度確認してください。HTTP リクエスト ブロックの場合は、HTTP リクエストとブロック設定が正しく構成されていることを確認してください。すべてのブロック設定が適切に構成されている場合は、サイトを再公開し、手順に変更を適用してみてください。 

サイトを再公開しても問題が解決しない場合は、画面を記録して 問題をWebflowロジックバグおよびフィードバックフォームに送信してください必ず 手順ID あなたの提出物と共に。 

共同作業者が Dispatch 電子メール通知ブロックに追加された後にサイトまたはワークスペースから削除された場合、何が起こりますか? 

以前の共同作業者は、Dispatch 電子メール通知ブロックからの電子メールを受信しなくなります。ただし、Dispatch 電子メール通知ブロック設定の共同作業者リストから削除されることはありません。手動で削除する必要があります。  

Logic を使用してサイトのコンテンツやデザインを変更することはできますか? 

CMSアイテムの作成とCMSアイテムの更新ブロックは、サイト上のコンテンツを変更するために使用できます。 作成する と定義されている ライブCMS コンテンツへのライブ変更を反映するには、サイトを更新する必要があることに注意してください。 

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

ウェブサイトをエクスポートした後もロジックは機能しますか?

ロジックのフロー (CMS および e コマース コンテンツと併せて) は、エクスポートされたコードに埋め込まれていません。ロジック操作は、適切な機能のためにホスティングに依存します。

ワークスペース内の他のメンバーが、私が入力した個人情報（サードパーティの API キー、ユーザー名、パスワードなど）を閲覧することは可能ですか?

Workspace メンバーは、資格情報にアクセスし、管理し、使用することができます。ただし、資格情報が生成されると、元の作成者であっても、Webflow UI で資格情報の実際の詳細を確認することはできません。基本的に、Workspace メンバーは資格情報に割り当てられたカスタマイズされた名前を表示できますが、実際のキーやトークンにアクセスすることはできません。

Webflow は資格情報をどのように保存および管理しますか?

資格情報は安全に保存され、送信中も保存中も常に暗号化されます。資格情報が確立されると、誰も、たとえ発信者であっても、Webflow UI 内で資格情報の実際の内容を見ることはできません。ユーザーは、生成された資格情報のユーザー定義のタイトルのみを見ることができます。

Webflow は資格情報を安全に保管していますが、ロジック フローを使用して資格情報を転送するサーバーや外部サービスに対しては管轄権を持たないことにご注意ください。

サイトの複製または転送中に資格情報はどうなりますか?

サイトの複製または転送中は、資格情報は保持されません。プロセスで使用される資格情報は、サイトの複製または転送が完了したら、新たに設定する必要があります。

ギャラリーからサイトを複製すると、フローもコピーされますか? 複製可能なサイトを通じてフローを共有できますか?

もちろんです。サイトを複製することは、サイト全体をクローンすることと同じです。フローを含め、サイトに関連付けられているすべての要素が、資格情報を除いて複製されます。プロセスに統合されている資格情報は、クローン作成プロセス後に再構成する必要があります。

フローを含むサイトを別のユーザーに譲渡した場合、譲渡されたサイトはフローを保持しますか?

確かにそうです。フローなど、サイトにリンクされているすべてのコンポーネントは、資格情報を除いて転送されます。サイトが転送されたら、プロセスで使用される資格情報を設定する必要があります。

サイトがバックアップから回復されると、フローはどうなりますか? フローは復元されますか、それとも変更されませんか?

バックアップを復元すると、フローはバックアップ作成時の状態に復元されます。ただし、サイトのフォームと CMS スキーマがバックアップと異なる可能性があるため、復元されたフローによって公開されたプロセスが中断される可能性があります。