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

なぜ変更されたのか
以前のページには、動作が正反対の2種類のスイッチがあり、どちらが表示されるかは、どのタブを開いているかによって異なっていました。
ほとんどのトリガーは「オプトイン」方式でした。つまり、ユーザーが有効にするまでは無効の状態でした。しかし、広範囲に及ぶ「... Update」のトリガーは「オプトアウト」方式でした。デフォルトでは有効になっており、最初のタブにはそれを無効にするための_抑制機能_が表示されていました。したがって、「スイッチがオフ」というのは、8つのタブでは「このトリガーは発動しない」ことを意味し、最初のタブでは「このトリガーは発動する」ことを意味していました。
さらに、トリガーのスイッチは、それをどのタブに分類しておいたかによってその場所が変わり、必ずしも探している場所にあるとは限りませんでした。検索機能もありませんでした。
ここで1つルールがあります。それは、**トリガーはスイッチがオンの間、作動するということです。**これはすべてのトリガーに当てはまります。
昔と今
| 以前 | さて | |
|---|---|---|
| どこで | 「設定」、9つのタブ | トリガー、1ページ |
| 引き金を見つける | タブを当ててみよう | 名前で検索 |
| 「スイッチ」の意味 | 8つのタブでオプトイン、最初のタブでサプレッサー | 常に:オン = 発火 |
| トリガーの抑制 | サプレッサーが_オン_になっています | トリガーが_オフ_になりました |
| 取材範囲 | タブ行を作成したトリガーのみ | 98個すべてのトリガー |
| いくつかをオンにする | 1つずつ | 確認画面を表示して、一括で有効化または無効化 |
| 権限不足 | 後で気づくんだ、何も発火しない時に | 行でフラグが立てられ、その場で承認された |
| カスタムトリガー | 別のページ | 同じページの上部 |
タブはどこへ行ったのか
現在は、すべてが1つのページにまとめられ、リソースごとにグループ分けされています。以前のタブ名は、各グループの見出しに対応しています:
| 古いタブ | さて |
|---|---|
| トリガー設定(サプレッサー) | 各リソースグループ内の広範な... Updateトリガー。通常のオン/オフスイッチのように表示されます。 |
| 注文トリガー | 注文 |
| ドラフト注文のトリガー | 注文(注文の草案) |
| 製品のトリガー | 製品 |
| 商品のバリエーション | 製品のバリエーション |
| 顧客トリガー | お客様 |
| コレクションのトリガー | コレクション |
| ポーリングトリガー | 分類:調査対象のリソース - 「**コンテンツ」**内のブログおよびページ、「**割引」**内の割引有効期限 |
| 市場 | 市場 |
| 在庫トリガー | 在庫 |
メタフィールドおよびメタオブジェクトのトリガーには、依然として個別のページが用意されています。これは、単一のスイッチを切り替えるのではなく、監視対象の定義を自分で選択するためです。
新着情報
**検索。**トリガー名の一部を入力すると、すべてのリソースから一度に検索できるため、見つかるまでタブを開き続ける必要がありません。
**すべてのトリガーは切り替え可能です。**以前は、トリガーにスイッチが割り当てられるのは、そのトリガー用に特別な行を作成した場合に限られていました。現在では、98個すべてのトリガーが、同じ制御を通じてスイッチを備えています。この制御はAPIやMCPでも使用されているものと同じであるため、ここで表示されている内容は、API呼び出し側からも同じように見えるものです。
**一括での有効化および無効化。**検索中は検索結果に、検索していないときはすべての項目に適用されます。どちらの場合も、まず確認を求められます。多数のトリガーを有効にすると月間使用量が増加する可能性があり、無効にすると稼働中のワークフローが停止します。
**権限は、操作を行ったその場で付与されます。**付与していない権限を必要とするトリガーを有効にすると、その場で権限の許可を求められます。トリガーに2つの権限が必要な場合(例:「注文の配送先住所が変更された」では「注文」と「顧客」の両方のアクセス権が必要です)は、順次表示されるのではなく、両方を網羅した1つのダイアログが表示されます。
拒否した場合、トリガーはオンのままとなり、自動的にオフに戻るのではなく、許可が必要な状態としてフラグが立てられます。
**「Storefront」および「Checkout」グループ。**アプリのウェブピクセルからデータが送信されるトリガーは、「**Storefront」および「Checkout」**の下に配置されており、これらはすべて初期状態で有効になっています。 2つの訪問トリガーには、スイッチの横に設定アイコンがあり、そこで訪問期間を設定できます。「**すべて有効にする」**を選択するとこれらのグループがすべて含まれるため、ストアが混雑している場合は、まず検索を行い、ワークフローで使用するトリガーのみを一括で有効にしてください。詳細は ストアフロントのトリガー をご覧ください。

権限は専用のページにまとめられました
「権限」は、ナビゲーション上で依然として独立したページとして表示されていますが、これは意図的なものです。いくつかの権限は個人データ(顧客レコード、注文の配送先住所、B2B企業の連絡先など)を対象としており、それらは各権限がどのような範囲をカバーしているかを確認できる専用の場所を設けるべきであり、設定項目のリストの下にある脚注のような場所に記載すべきではないからです。
また、ここで権限を取り消すこともできます。1つの権限は複数のトリガーを一度にカバーしているため、これを1つ取り消すことは、「トリガー」ページ上の個別のスイッチ操作よりも広範囲にわたる操作となります。
状況に合わせて適切な方法をお選びください。トリガーを単に動作させたいだけなら、トリガー行から「grant in passing」を設定するか、あるいは「権限」ページで全体像を確認してください。
ベースラインの同期
変更なし。変更検出トリガーを有効にすると、ベースライン同期がキューに入れられるため、次回の変更が発生した際に比較対象が確保されます。これを有効にしないと、有効化後の最初の変更は黙って無視されてしまいます。
小規模な店舗の場合は数秒程度、10万点以上の商品を取り扱うカタログの場合は最大で約20分ほどかかります。処理中はページが自動的に更新されます。
まだ権限が付与されていない場合、同期は失敗するのではなく延期されます。権限を付与すれば、自動的に開始されます。
これらを手動で行う必要はほとんどありません。トリガーを使用するShopify Flowワークフローを有効にすると、トリガーが作動し、同期が自動的に開始されます。
手動での再同期
「トリガー」ページの下部にある「**データ同期」**セクションには、リソースごとに「再同期」ボタンがあります。権限が長期間取り消されていた場合や、トリガーがオフの状態で大規模なインポートが行われた後など、ベースラインがずれてしまったと思われる場合は、このボタンを使用してください。
同期に失敗した場合、そのセクションにその旨と理由が表示されます。アプリ内の他のどこにも「デッドバックフィル」に関する表示は現れません。なお、「デッドバックフィル」とは、すでに存在していたレコードに対してはトリガーが発火しないことを意味します。

