設定「トリガー」ページ(旧「設定」)

「トリガー」ページ(旧「設定」)

ページをコピーする

9つのタブで構成されていた「設定」ページは、各トリガーに個別のオン/オフスイッチが備わった単一の「トリガー」ページに変更されました。どの機能がどこに移動したのか、またどのような新機能が追加されたのかをご紹介します。

「トリガー」ページには、組み込みトリガーごとに1つのスイッチが表示され、リソースごとにグループ分けされています
組み込みのトリガーには、それぞれ独自のスイッチがあります。グループの横にある数字は、そのグループ内のトリガーのうち、オンになっているものの数を示しています。

なぜ変更されたのか

以前のページには、動作が正反対の2種類のスイッチがあり、どちらが表示されるかは、どのタブを開いているかによって異なっていました。

ほとんどのトリガーはオプトイン方式でした。つまり、ユーザーが有効にするまでは無効の状態でした。しかし、広範な... Updateトリガーはオプトアウト方式でした。デフォルトでは有効になっており、最初のタブにはそれらを無効にするための_抑制機能が_用意されていました。したがって、「スイッチがオフ」というのは、8つのタブでは「このトリガーは発動しない」ことを意味し、最初のタブでは「このトリガーは発動する」ことを意味していました。

さらに、トリガーのスイッチは、それをどのタブに分類しておいたかによって場所が変わり、必ずしも探している場所にあるとは限りませんでした。検索機能もありませんでした。

ここで、1つのルールがあります。それは、**トリガーはスイッチがオンの間、作動するということです。**これはすべてのトリガーに当てはまります。

以前と現在

以前 さて
どこで 「設定」、9つのタブ トリガー、1ページ
トリガーを見つける タブを当ててみてください 名前で検索する
「スイッチ」の意味とは 8つのタブでオプトイン、最初のタブでサプレッサー 常に:オン = 発火します
サイレンサー付きトリガー サプレッサーが_オン_になりました トリガーが_オフ_になっています
取材範囲 タブ行を作成したトリガーのみ 98個すべてのトリガー
いくつかをオンにする 一つずつ 確認画面を表示して、一括で有効化または無効化します
権限が不足しています 後で、何も反応しなくなった時に気づくことになるでしょう 行でフラグが立てられ、その場で承認されました
カスタムトリガー 別のページ 同じページの上部

タブはどこへ行ったのでしょうか

現在は、すべてが1つのページにまとめられ、リソースごとにグループ分けされています。以前のタブ名は、グループの見出しに対応しています:

古いタブ さて
トリガー設定(サプレッサー) 各リソースグループ内の、通常のオン/オフスイッチとして表示される広範な... Updateトリガー
注文トリガー 注文
下書き注文のトリガー 注文(下書き注文)
製品のトリガー 製品
商品バリエーション 商品バリエーション
顧客トリガー お客様
コレクションのトリガー コレクション
ポーリングのトリガー 調査対象のリソースごとに分類されています。「コンテンツ」内のブログやページ、「**ディスカウント」**内のディスカウント有効期限
マーケット マーケット
在庫トリガー 在庫

メタフィールドおよびメタオブジェクトのトリガーについては、依然としてそれぞれ個別のページが用意されています。これは、単一のスイッチを切り替えるのではなく、監視対象となる定義を個別に選択するためです。

新着情報

**検索。**トリガー名の一部を入力すると、すべてのリソースから一度に検索できます。目につくまでタブを開き続ける必要はありません。

**すべてのトリガーは切り替え可能です。**以前は、トリガーにスイッチが割り当てられるのは、そのトリガー用に列を作成した場合に限られていました。現在では、98個すべてのトリガーが、同じ制御を通じてスイッチを備えています。この制御はAPIやMCPでも使用されているものと同じであるため、ここで表示されている内容は、API呼び出し元から見たものと同じです。

**一括での有効化および無効化です。**検索中は検索結果に、検索していないときはすべての項目に適用されます。どちらの場合も、まず確認を求められます。多数のトリガーを有効にすると、月間使用量が増加する可能性があります。また、無効にすると、実行中のワークフローが停止します。

**権限は、該当する箇所で付与されます。**付与されていない権限を必要とするトリガーを有効にすると、その場で権限の許可を求められます。トリガーに2つの権限が必要な場合(例:「注文の配送先住所が変更された」トリガーには「注文」と「お客様」の両方のアクセス権が必要です)は、順次表示されるのではなく、両方を網羅した1つのダイアログが表示されます。

お断りされた場合、トリガーはオンのままとなり、許可が必要である旨のフラグが立てられます。黙って自動的にオフに戻ることはありません。

**「ストアフロント」および「チェックアウト」グループです。**アプリのウェブピクセルからデータが送信されるトリガーは、「**ストアフロント」および「チェックアウト」**の下に配置されており、これらはすべて初期状態で有効になっています。 2つの訪問トリガーのスイッチの横には設定アイコンがあり、そこで訪問期間を設定できます。「**すべて有効にする」**を選択するとこれらのグループがすべて含まれますので、ストアが混雑している場合は、まず検索を行い、ワークフローで使用するトリガーのみを一括で有効にしてください。ストアフロントのトリガーをご参照ください。

「Which」は、製品フィールドのツリー構造を含むこの「製品更新」ダイアログを更新します。
「製品更新」、「注文更新」、「顧客更新」の設定アイコンの背面で、トリガーを起動させたい項目にチェックを入れてください。何もチェックされていない場合は、更新のたびにトリガーが起動します。

権限は専用のページにまとめられました

「権限」は、ナビゲーション上で依然として独立したページとして表示されていますが、これは意図的なものです。いくつかの権限は個人データ(顧客レコード、注文の配送先住所、B2B会社の連絡先など)を対象としており、それらは、各権限がどのような範囲をカバーしているかを確認できる専用の場所を設けるべきであり、設定項目のリストの下にある脚注のような場所には置くべきではないからです。

また、ここで権限を取り消すこともできます。1つの権限は複数のトリガーを一度にカバーしているため、1つの権限を取り消すことは、「トリガー」ページ上の個々の切り替え操作よりも広範囲にわたるアクションとなります。

状況に合わせて、どちらでもお使いください。トリガーを単に動作させたいだけなら、トリガー行から簡単に権限を付与するか、あるいは「権限」ページで全体像を確認してください。

ベースラインの同期

変更はありません。変更検出トリガーを有効にすると、ベースライン同期がキューに入れられます。これにより、次回の変更が発生した際に比較対象が確保されます。これを有効にしないと、有効化後の最初の変更は黙って無視されてしまいます。

フィールドの選択内容を保存すると、この処理が「製品更新」、「注文更新」、または「顧客更新」のいずれのキューで実行されるかによって、同じ同期処理がキューに入れられます。レコードが保存されるまでは、選択内容を伴う最初の更新がそのレコードの起点として扱われ、この処理は実行されません。何もチェックされていない場合は、従来通り処理が実行されます。

小規模なストアの場合は数秒程度、10万点以上の商品を取り扱うカタログの場合は最大で約20分ほどかかります。処理中はページが自動的に更新されます。

権限がまだ付与されていない場合、同期は失敗するのではなく、延期されます。権限を付与すれば、自動的に開始されます。

これらを手作業で行う必要はほとんどありません。トリガーを使用するShopify Flowワークフローを有効にすると、トリガーが作動し、自動的に同期が開始されます。

手動での再同期

「トリガー」ページの下部にある「データ同期」セクションには、リソースごとに「再同期」ボタンがあります。権限が取り消された状態が長期間続いた後や、トリガーがオフの状態で大規模なインポートが行われた後など、ベースラインにずれが生じていると思われる場合は、このボタンをご利用ください。

同期に失敗した場合、そのセクションにその旨と理由が表示されます。アプリ内の他のどこにも、バックフィルが失敗したことは表示されません。また、バックフィルが失敗すると、すでに存在していたレコードに対してはトリガーが発動しなくなります。