自動化の構築と管理

自動化ルールは具体的で、テスト可能で、説明しやすいものである必要があります。強力なルールでは、明確なトリガー、狭い条件、安全なアクション、および制御された範囲が使用されます。

安全な自動化セットアップは次のことに役立ちます。

1. 新しい自動化ルールを計画します。
2. 自動化ビルダーでルールを作成します。
3. 既存のルールを確認して変更します。
4. アクセス、プラン、ネットワーク要件を確認します。
5. 信頼する前に動作をテストしてください。

ビルダー状態リファレンス

州	何をすべきか
読み込み中	ビルダーが初期化されるまで待ちます。
再試行	「再試行」を選択します。繰り返し発生する場合は、アプリを更新してネットワーク アクセスを確認してください。
インターネットなし	ルールを開いたり変更したりする前に、再接続してください。
アクセス不可	スペース管理者に自分の役割を確認してもらいます。
アップグレードのプロンプト	請求先の所有者にプランの利用可能性を確認するよう依頼してください。
ビルダーがロードされました	ビルダーからルールを作成、確認、管理します。

ルール設計リファレンス

パート	定義	良い習慣
名前	ビルダー内でユーザーに表示されるラベル。	タスクがレビューに移行するときにレビュー担当者を割り当てるなど、わかりやすい目的を使用します。
トリガー	ルールを開始するイベント。	利用可能な最も具体的なイベントを選択してください。
状態	アクションを実行する前に満たす必要がある要件。	偶発的な一致を防ぐために条件を追加します。
アクション	実行された更新、通知、割り当て、リマインダー、またはその他の操作。	最初のバージョンはリスクを低く保ちます。
範囲	ルールが適用されるスペース、リスト、または作業領域。	最初は狭い範囲から開始し、テスト後にのみ拡張します。
ステータス	ルールを実行できるかどうか。	予期しない動作を調査している間、ルールを一時停止または無効にします。

始める前に

• あなたは正しいスペースにいる必要があります。
• あなたの役割は自動化アクセスを許可する必要があります。
• プランには自動化アクセスが含まれている必要があります。
• 実際の作業でルールに頼る前に、安全なテスト項目を使用してください。

構築する前にルールを計画する

ルールを次の形式で記述します。

[トリガー]が発生し、[条件]が真であれば[アクション]が発生します。

例:

• タスクがレビューに移行したら、レビュー担当者を割り当てます。
• タスクがブロックされているとマークされたら、チームに通知します。
• フォローアップの日付が追加されたら、リマインダーを作成します。

オートメーションを作成する

1. オートメーションを開きます。
2. ビルダーがロードされるまで待ちます。
3. 新しいルールを開始します。
4. ルールに明確な名前を付けます。
5. トリガーを選択します。
6. 条件を追加します。
7. アクションを選択します。
8. 範囲を確認します。
9. ルールを保存します。
10. 安全なアイテムでテストしてください。

期待される結果: オートメーションは保存され、マッチング作業にのみ影響します。

既存のオートメーションを管理する

1. オートメーションを開きます。
2. 確認したいルールを選択します。
3. 名前、トリガー、条件、アクション、スコープ、ステータスを確認します。
4. 動作が不確かな場合は、ルールを一時停止または無効にします。
5. 一度に 1 つのパートを編集します。
6. 保存して再テストします。

安全なセットアップのチェックリスト

ルールに依存する前に、次のことを確認してください。

1. トリガーは具体的です。
2. 条件により部分一致が妨げられます。
3. アクションは安全です。
4. 範囲は意図した領域に限定されます。
5. テスト項目が期待どおりの結果をもたらしました。
6. 影響を受けるチームは自動アップデートを理解しています。
7. 必要に応じてルールを一時停止または無効にする方法を理解しています。

トラブルシューティング

ビルダーで「再試行」が表示され続ける

• 症状: 再試行してもビルダーが開きません。
• 原因: セッション、ネットワーク、サービスの可用性、または初期化の詳細が欠落している可能性があります。
• 解決策:
  1. オンラインになっていることを確認します。
  2. アプリを更新します。
  3. 現在のスペースが正しくロードされていることを確認します。
  4. もう一度試してください。
  5. それでも失敗する場合は、おおよその時間とスペースを報告します。

ルールが多くの作業に影響を与える

• 症状: 予想よりも多くの項目が変更されます。
• 原因: トリガー、条件、または範囲が広すぎます。
• 解決策:
  1. 可能な場合はルールを一時停止または無効にします。
  2. 範囲が狭い。
  3. より厳しい条件を追加します。
  4. 1 つの一致する項目と 1 つの不一致の項目を使用してテストします。

自動的な変更に人々は驚く

• 症状: チーム メンバーは、作業が変更された理由を知りません。
• 原因: ルール名またはチームプロセスでは自動化を説明できない可能性があります。
• 解決策:
  1. 目的が明確になるようにルールの名前を変更します。
  2. 影響を受けるユーザーに、アクションを引き起こすトリガーを伝えます。
  3. リスクの高い意思決定はマニュアルで行います。

FAQ

新しいルールはどの程度の範囲にすべきでしょうか?

狭く始めてください。安全なテストで動作が証明された場合にのみ拡張してください。

予期しない更新が発生しているときにルールを編集する必要がありますか?

ビルダーがそのオプションを提供している場合は、最初にそれを一時停止または無効にします。次に、編集、テストし、再度有効にします。