snapshot of https://github.com/twentyhq/twenty.git (main, 2026-09-17; blobs > 131072B omitted)
Some checks failed
App Prod-Parity E2E Dispatch / dispatch (push) Failing after 10s
CD Storybook UI / build (push) Failing after 3m25s
CD Storybook UI / dispatch (push) Has been skipped
CD deploy main / website-changed-files (push) Successful in 18m8s
CI Agent Skills / changed-files-check (push) Successful in 18m9s
CI Create App E2E minimal / changed-files-check (push) Successful in 24s
CI Create App / changed-files-check (push) Successful in 26s
CI Docs / changed-files-check (push) Successful in 26s
CI Emails / changed-files-check (push) Successful in 28s
CI Example App Hello World / changed-files-check (push) Successful in 23s
CI Front / changed-files-check (push) Has been skipped
CI Example App Postcard / changed-files-check (push) Successful in 27s
CI UI / changed-files-check (push) Has been skipped
CI Utils Test / changed-files-check (push) Successful in 45s
CI Twenty Apps / discover (push) Successful in 1m3s
CD deploy main / deploy-main (push) Failing after 3s
CI Agent Skills / agent-skills-validate (push) Has been skipped
CI Create App / create-app-test (lint) (push) Has been skipped
CI Emails / emails-test (push) Has been skipped
CI Front / front-task (lingui:compile) (push) Has been skipped
CI Front / front-task (lint) (push) Has been skipped
CI Example App Postcard / example-app-postcard (push) Has been skipped
CI UI / ui-task (lint) (push) Has been skipped
CI UI / ui-task (pack-size) (push) Has been skipped
CI UI / ui-task (size) (push) Has been skipped
CI UI / ui-task (test) (push) Has been skipped
CI UI / ui-task (typecheck) (push) Has been skipped
CI Utils Test / utils-test (push) Has been skipped
CI Twenty Apps / ${{ matrix.app.name }} (push) Has been skipped
CI Emails / ci-emails-status-check (push) Successful in 2s
CI Example App Hello World / ci-example-app-hello-world-status-check (push) Successful in 2s
CI Example App Postcard / ci-example-app-postcard-status-check (push) Successful in 3s
CI UI / ui-sb-test (push) Has been skipped
CI Utils Test / ci-utils-test-status-check (push) Successful in 2s
CI Twenty Apps / ci-twenty-apps-status-check (push) Successful in 2s
CI UI / ci-ui-status-check (push) Successful in 2s
CI Desktop / desktop (push) Failing after 1m8s
Push docs to Crowdin / Push documentation to Crowdin (push) Failing after 55s
Push translations to Crowdin / Extract and upload translations (push) Failing after 5s
Push website translations to Crowdin / Extract and upload website translations (push) Failing after 5s
CI Create App / create-app-test (test) (push) Has been skipped
CI Create App / create-app-test (typecheck) (push) Has been skipped
CI Docs / docs-lint (push) Has been skipped
CI Example App Hello World / example-app-hello-world (push) Has been skipped
CI Front / front-task (lingui:extract) (push) Has been skipped
CI Front / front-task (test) (push) Has been skipped
CI Front / front-task (typecheck) (push) Has been skipped
CI UI / ui-sb-build (push) Failing after 1m32s
CI Twenty Apps / ${{ matrix.app.name }} (${{ matrix.server-source }}) (push) Has been skipped
CI Agent Skills / agent-skills-publish (push) Has been skipped
CI Create App / ci-create-app-status-check (push) Successful in 2s
CI Agent Skills / agent-skills-remote-source (push) Has been skipped
CI Create App E2E minimal / create-app-e2e-minimal (push) Has been cancelled
CI E2E Main / e2e-test (push) Has been cancelled
CI Front / front-sb-build (push) Has been cancelled
CI Front / front-build (push) Has been cancelled
CI Create App E2E minimal / ci-create-app-e2e-minimal-status-check (push) Has been cancelled
CI E2E Main / ci-e2e-main-status-check (push) Has been cancelled
CI E2E Main / notify-main-ci-failure (push) Has been cancelled
CI E2E Main / qa-scout-comment (push) Has been cancelled
CI Front / front-sb-test (push) Has been cancelled
CI Front / front-sb-screenshots (push) Has been cancelled
CI Front / ci-front-status-check (push) Has been cancelled
DPA Sub-Processor Sync / sync-subprocessors (push) Failing after 3s
AI Catalog Sync / sync-catalog (push) Failing after 2s

This commit is contained in:
upstream-mirror
2026-09-17 23:28:13 +05:00
commit e7da97194a
32688 changed files with 4208681 additions and 0 deletions

View File

@@ -0,0 +1,167 @@
---
title: ワークフローによるメール送信
description: ワークフローアクションを使用して、パーソナライズされたメールを自動送信します。
---
CRM で特定のイベントが発生したときにメールを自動送信します—新規連絡先を歓迎し、商談をフォローアップしたり、チームメンバーに通知したりします。
## 前提条件
ワークフローからメールを送信する前に:
1. **設定 → アカウント** でメールアカウントを接続する
2. そのアカウントで送信権限が有効になっていることを確認する
## 基本的なメールワークフロー
### 例:新規連絡先へのウェルカムメール
**目的**: 新しい連絡先が CRM に追加されたときにウェルカムメールを送信する。
**設定**:
1. **ワークフローを作成**: **設定 → ワークフロー** に移動し、**+ New Workflow** をクリック
2. **トリガーを追加**: **Record is Created** → **People** を選択
3. **Send Email アクションを追加**:
* アクションを追加するには **+** をクリック
* **Send Email** を選択
* メールを設定:
| フィールド | 値 |
| ------ | -------------------------------------- |
| **宛先** | `{{trigger.object.email}}` |
| **件名** | `{{Your Company Name}}へようこそ` |
| **本文** | `Hi {{trigger.object.firstName}}, ...` |
4. **テストして有効化**: サンプルレコードでテストし、その後有効化する
## メールで変数を使用する
`{{variable}}` 構文を使用して前のステップのデータを参照します:
```text
Hi {{trigger.object.firstName}},
Thank you for connecting with us!
Your company, {{trigger.object.company.name}}, is now in our system.
Best regards,
The Team
```
### トリガーから利用できる変数
| トリガータイプ | 一般的な変数 |
| -------------- | -------------------------------------- |
| **レコードの作成/更新** | `{{trigger.object.fieldName}}` |
| **手動** | `{{trigger.selectedRecord.fieldName}}` |
| **Webhook** | `{{trigger.body.fieldName}}` |
## 高度: 条件付きメール
### 例:リードのソースに基づいて異なるメール
**目的**: リードの流入元に応じて異なるウェルカムメールを送信する。
**設定**:
1. **トリガー**: レコードが作成される(People)
2. **フィルターアクションを追加**:
* 条件: `{{trigger.object.source}}` が "Website" と等しい
* 真の場合 → ウェブサイトのウェルカムメールに進む
3. **その他のソース用の分岐**:
* ソースごとに並列の分岐を作成する
* 各分岐にそれぞれの Send Email アクションを配置する
## 複数の受信者にメールを送信する
### 例:商談が成立したときにチームへ通知
**目的**: 商談が成約したときに担当営業とそのマネージャーへメールを送る。
**設定**:
1. **トリガー**: レコードが更新(Opportunities、Stage = "Closed Won")
2. **Search Records**: 商談の所有者のマネージャーを見つける
3. **Send Email #1**: 商談の所有者宛て
* 宛先: `{{trigger.object.owner.email}}`
* 件名: `Congratulations on closing {{trigger.object.name}}!`
4. **Send Email #2**: マネージャー宛て
* 宛先: `{{searchRecords.manager.email}}`
* 件名: `Deal Won: {{trigger.object.name}}`
## フォローアップメールのスケジュール送信
### 例:会議の3日後にフォローアップ
**目的**: 会議が記録された3日後にフォローアップメールを送信する。
**設定**:
1. **トリガー**: レコードが作成(Activities、Type = "Meeting")
2. **Delay アクション**: 3日待機
3. **Send Email**:
* 宛先: 会議の参加者
* 件名: 先日の会話のフォロー
* 本文: トリガーから会議の詳細を参照
## メールの添付ファイル
ワークフローから送信されるメールにファイルを添付できます。 添付ファイルは、ワークフローを設定する際にアップロードする静的なファイルです。
### 添付ファイルを追加する方法
1. **メール送信** アクションで、**添付ファイル** ボタンをクリックします
2. クリックしてお使いのコンピューターからファイルをアップロードします
3. このアクションによって送信されるすべてのメールに、そのファイルが添付されます。
### 一般的な使用例
| ユースケース | サンプルファイル |
| ----------------- | --------------- |
| **ウェルカムメール** | 会社案内(PDF) |
| **オンボーディングシーケンス** | 導入ガイド |
| **営業のフォローアップ** | 製品カタログまたは価格表 |
| **イベント確認メール** | イベントの詳細またはアジェンダ |
<Note>
添付ファイルは静的です—すべての受信者に同じファイルが送信されます。 動的ドキュメント(パーソナライズされた見積もりなど)の場合は、[ロジック関数](/l/ja/user-guide/workflows/how-tos/connect-to-other-tools/generate-pdf-from-twenty)を使ってファイルを生成し、添付します。
</Note>
## ベストプラクティス
### メールの内容
* 件名は簡潔かつ関連性の高い内容に保つ
* 受信者名でパーソナライズする
* 明確な行動喚起を含める
* 有効化前にメールをテストする
### 到達性
* 短時間に過度な数のメールを送信しない
* プロフェッショナルなメール署名を使用する
* スパム判定されやすい語句を避ける
* マーケティングメールに配信停止オプションを必ず用意する
### トラブルシューティング
* メールアカウントが接続され有効になっていることを確認する
* 受信者のメールアドレスが有効か確認する
* エラーメッセージがないかワークフローの実行履歴を確認する
* まず自分のメールアドレスでテストする
## 関連
* [ワークフローのトリガー](/l/ja/user-guide/workflows/capabilities/workflow-triggers)
* [ワークフローのアクション](/l/ja/user-guide/workflows/capabilities/workflow-actions)

View File

@@ -0,0 +1,88 @@
---
title: ワークフローでブランチを使用する
description: ブランチの仕組みと、どのパスが実行されるかの制御方法を理解します。
---
## ブランチの仕組み
ワークフローエディタでは、1 つのノードから分岐する複数のパス(ブランチ)を作成できます。 これにより、異なる結果を持つ複雑な自動化を構築できます。
**重要**: ワークフローが実行されると、**既定ではすべてのブランチが並列に実行されます**。 あるブランチを選択するための組み込みの "if/else" ロジックはありません—すべてのパスが同時に実行されます。
## どのブランチを実行するかの制御
特定の条件に基づいて 1 つのブランチのみを実行するには、**各ブランチの先頭に Filter ノードを追加**します。
### セットアップ例
1. 1 つのノードから複数のブランチを持つワークフローを作成します
2. 各ブランチの最初のステップとして **Filter** ノードを追加します
3. 各 Filter に条件を設定し、そのブランチをいつ続行するかを決めます
4. Filter の条件を満たしたブランチだけが続行します
### Filter の仕組み
* Filter の条件が**満たされた**場合:ブランチは実行を継続します
* Filter の条件が**満たされない**場合:ブランチは Filter ノードで停止します
これにより、データに基づいて該当するブランチだけが実行される条件付きロジックを実質的に作成できます。
## 例:商談金額でルーティング
**シナリオ**: 商談がクローズされたとき、商談金額に応じて異なる通知を送信します。
1. **トリガー**: Opportunity が更新(Stage = Closed Won)
2. **ブランチ 1**: Amount > $10,000 で Filter → #big-deals に Slack メッセージを送信
3. **ブランチ 2**: Amount ≤ $10,000 で Filter → 営業マネージャーにメールを送信
両方のブランチが開始されますが、商談金額に一致する方だけが Filter を通過して続行します。
## ブランチの作成
<Note>
既存のステップから新しいブランチを作成するには、そのステップの **+** ボタンをクリックしてアクションを追加します。 **+** を複数回クリックすると、複数のブランチを追加できます。
</Note>
1. ワークフローエディタで、分岐させたいステップを選択します
2. アクションを追加するには **+** ボタンをクリックします
3. これで 1 つのブランチが作成されます
4. 同じステップで **+** をもう一度クリックして、ブランチを追加作成します
5. 各ブランチは独自のアクションのシーケンスを持てます
## ブランチを再結合する
並列ブランチが処理を完了したら、単一のパスに再結合できます:
1. 分岐したアクションを完了します
2. すべてのブランチの後に実行すべき新しいステップを追加します
3. 各ブランチの最後のステップからこの新しいステップに接続をドラッグします
4. マージされたステップは、接続されたすべてのブランチが完了するまで待機してから実行されます
### 例:処理後に通知
```
Trigger
│
├── Branch A: Update Customer Record
│
└── Branch B: Create Support Ticket
↘ ↙
Merged Step: Send Confirmation Email
```
確認メールは、お客様の更新とチケット作成の両方が完了した後に送信されます。
## ベストプラクティス
* 条件付きで実行したい場合は、ブランチの開始時に常に**Filter ノード**を使用します
* 重複したアクションを避けるために、ブランチの条件は**相互排他的**に保ちます
* さまざまなデータでワークフローをテストし、正しいブランチが実行されることを確認します
* **ブランチのステップ名を変更**して、各パスが何を行うかが明確に分かるようにします
* 並列処理の後に最終アクションが必要な場合は、**ブランチをマージ**します
## 関連
* [ワークフロー FAQ](/l/ja/user-guide/workflows/how-tos/need-more-help/workflows-faq) — 並列実行に関する回答
* [ワークフローのアクション](/l/ja/user-guide/workflows/capabilities/workflow-actions) — ブランチで利用可能なアクション

View File

@@ -0,0 +1,183 @@
---
title: Iterator を使用
description: レコードの配列をループし、各アイテムに対してアクションを実行します。
---
Iterator を使用すると、レコードの配列をループし、各レコードに対してアクションを実行できます。 これは、Search Records で返された複数のレコードや Webhook で受信したレコードを処理する必要があるワークフローに不可欠です。
## Iterator を使用するタイミング
| シナリオ | 例 |
| ------------------ | ------------------ |
| **検索結果を処理** | 見つかった各人物にメールを送信 |
| **Webhook の配列を処理** | 各アイテムごとに順番にレコードを作成 |
| **一括更新** | 計算された値で複数のレコードを更新 |
| **通知** | イベントについて複数人に通知 |
## Iterator の理解
Iterator は入力として**配列**を想定しています。 その後、次を実行します:
1. 配列から最初のアイテムを取り出す
2. そのアイテムを使って Iterator 内のすべてのアクションを実行する
3. 次のアイテムに進む
4. すべてのアイテムが処理されるまで繰り返す
### ループ処理する配列の選択
ほとんどの配列ソース(Search Records、webhook の配列フィールド、Bulk manual trigger)は、変数ピッカーで直接選択できます。
**Code** ステップや **Logic Function** ステップが*トップレベル配列*を返す場合、その出力は変数ピッカー内でインデックス付きエントリ(`0`、`1`、`2`、…)として表示されます。 配列全体をループ処理するには、そのステップの **Whole list** オプションを選択します。Iterator は、そのリストから各アイテムの構造を自動的に推論します。
## 基本的なセットアップ
### 例: 検索結果の全員にメールを送信
**目標**: 特定の会社のすべての連絡先を見つけ、各人にパーソナライズされたメールを送信します。
### ステップ 1: レコードを検索
1. 「**Search Records**」アクションを追加
2. オブジェクト: **People**
3. フィルター: Company が "Acme Inc" に等しい
4. これにより、People の配列が返されます
### ステップ 2: 結果の有無を確認
1. 「**Filter**」アクションを追加
2. 条件: `{{searchRecords.length}}` が 0 より大きい
3. これにより、結果が空の場合の Iterator エラーを防止します
### ステップ 3: Iterator を追加
1. 「**Iterator**」アクションを追加
2. 配列の入力: `{{searchRecords}}` を選択
3. これでループが作成されます
### ステップ 4: Iterator 内にアクションを追加
Iterator の後に配置したアクションは、各アイテムに対して実行されます:
1. Iterator 内に **Send Email** アクションを追加する
2. 宛先: `{{iterator.currentItem.email}}`
3. 件名: こんにちは `{{iterator.currentItem.firstName}}`!
4. 本文: 現在のアイテムのフィールドを使用したパーソナライズメッセージ
### 結果
Search Records が 5 人を返した場合、Iterator は次を実行します:
* 1 人目にメールを送信
* 2 人目にメールを送信
* ... 5 人すべてに対して続行
## 現在のアイテムのデータにアクセスする
Iterator 内では、現在のレコードにアクセスするために `{{iterator.currentItem}}` を使用します:
| 変数 | 説明 |
| --------------------------------------- | ---------------- |
| `{{iterator.currentItem}}` | 現在のレコードオブジェクト全体 |
| `{{iterator.currentItem.id}}` | レコード ID |
| `{{iterator.currentItem.email}}` | メールフィールド |
| `{{iterator.currentItem.company.name}}` | 関連する会社名 |
| `{{iterator.index}}` | 配列内の現在の位置(0 始まり) |
変数ピッカーでは、現在のアイテムの特定のフィールドまでドリルダウンして選択するか、**Use the whole item** を選択して、現在のアイテム全体(`{{iterator.currentItem}}`)を参照できます。 アイテム全体を選択すると、フィールドを 1 つずつ再構築するのではなく、完全なレコードをそのまま後続ステップに渡したい場合に便利です。
## よくあるパターン
### 複数レコードを更新
**目標**: 期限超過のタスクをすべて "Late" としてマークします。
```
1. Search Records (Tasks, Due Date < Today, Status ≠ Completed)
2. Filter (length > 0)
3. Iterator (searchRecords)
└── Update Record
- Object: Tasks
- Record: {{iterator.currentItem.id}}
- Status: Late
```
### 配列からレコードを作成
**目標**: 複数のアイテムを含む注文を Webhook が受信したら、各アイテムのレコードを作成します。
```
1. Webhook Trigger (receives items array)
2. Filter (items.length > 0)
3. Iterator (trigger.body.items)
└── Create Record
- Object: Order Items
- Name: {{iterator.currentItem.name}}
- Quantity: {{iterator.currentItem.qty}}
- Related Order: {{trigger.body.orderId}}
```
### ループ内の条件付き処理
**目標**: 有効なメールアドレスを持つ連絡先にのみメールを送信します。
```
1. Search Records (People)
2. Iterator (searchRecords)
└── Filter (currentItem.email is not empty)
└── Send Email
- To: {{iterator.currentItem.email}}
```
## トラブルシューティング
### "Iterator expects an array"
**原因**: 配列ではなく単一のレコードを渡しました。
**対処**: 単一のレコードではなく、Search Records の結果または配列フィールドを渡していることを確認してください。
```
✅ Correct: {{searchRecords}}
❌ Wrong: {{searchRecords[0]}}
```
### Iterator が実行されない
**原因**: 配列が空です。
**対処**: Iterator の前にフィルターを追加し、配列の長さを確認します:
```
Filter: {{searchRecords.length}} > 0
```
### アクションが過剰に実行される
**原因**: Search Records が想定より多くのレコードを返しました。
**対処**:
* Search Records により具体的なフィルターを追加する
* Search Records に上限を設定する(最大 200)
* 追加条件のために Iterator 内にフィルターを追加する
## パフォーマンス上の考慮事項
* **クレジット使用量**: 各イテレーションでアクション実行分のクレジットを消費します
* **時間**: 大きな配列は処理に時間がかかります
* **制限**: 非常に大きな処理はバッチ化を検討してください
* **レート制限**: 繰り返しが多いと外部 API 呼び出しがレート制限に達する可能性があります
## ベストプラクティス
1. エラーを避けるため、Iterator の前に**配列の長さを必ず確認**
2. **すべてのアイテムを処理する必要がない場合はループ内にフィルターを追加**
3. **何をループしているか分かるように Iterator ステップの名前を変更**
4. **小さな配列でテスト**してから大きなデータセットを処理する
5. **ワークフローの実行を監視**して、イテレーションが想定どおりに完了することを確認する
## 関連
* [ワークフローのアクション](/l/ja/user-guide/workflows/capabilities/workflow-actions)
* [ブランチの使い方](/l/ja/user-guide/workflows/capabilities/use-branches-in-workflows)
* [ワークフロー FAQ](/l/ja/user-guide/workflows/how-tos/need-more-help/workflows-faq)

View File

@@ -0,0 +1,332 @@
---
title: ワークフローアクション
description: Twenty のワークフローで利用可能なアクションについて学びましょう。
---
import { VimeoEmbed } from '/snippets/vimeo-embed.mdx';
## アクションについて
アクションはトリガーが起動した後に何が起こるかを定義します。 複数のアクションを連結して、複雑な自動化を構築できます。
<Tip>
* 変数ピッカー(`(x+)` アイコンをクリック)を使用して、前の手順から利用可能なデータを参照します
* 任意の入力フィールドにカーソルを合わせると、変数がどのステップから来ているかがわかります—同じフィールド(例:ID)が複数の前のステップに存在する場合に便利です
* 保守しやすくするため、各アクションにわかりやすい名前を付けてください
</Tip>
## レコードアクション
<img src="/images/user-guide/workflows/workflow_actions.png" style={{width:'100%'}} />
### レコードを作成
選択したオブジェクトに新しいレコードを追加します。
**設定**:
* 対象オブジェクトを選択
* 必要およびオプションのフィールドに入力
* 前の手順のデータを使用するか、手動で値を入力してフィールドに設定します
**出力**:新しく作成されたレコードのデータが後続の手順で使用可能
### レコードを更新
選択したオブジェクト内の既存のレコードを変更します。
<img src="/images/user-guide/workflows/update_record.png" style={{width:'100%'}} />
**設定**:
* 対象オブジェクトを選択
* 更新する具体的なレコードを選択.
* 利用可能なすべてのレコードを表示するドロップダウンメニューから、固定のレコードを選択できます。
* または、`(x+)` を使用して前のステップで見つかったレコードを指定し、レコードを動的に選択できます。 この段階では、異なる条件に基づいてレコードを検索することはできません。 まだレコードを特定していない場合は、この `Update Record` ステップの前に `Search Record` ステップを追加してください。
* 変更するフィールドを選択し、新しい値を入力
**出力**:更新されたレコードのデータが後続の手順で使用可能
### レコードを削除
選択したオブジェクトからレコードを削除します。
**設定**:
* 対象オブジェクトを選択
* 削除する具体的なレコードを選択
**出力**:削除されたレコードのデータは後続の手順で使用可能
### レコードを検索
選択したオブジェクト内のフィルター条件を使用してレコードを探します。
**設定**:
* 検索するオブジェクトを選択
* 結果を絞り込むためのフィルター基準を設定
* 並べ替えや制限を設定
**出力**:一致するレコードを返し、後続の手順で使用可能
<Note>
**制限**:Search Records は最大 **200 件のレコード**を返します。 さらに処理する必要がある場合は、結果を絞り込むフィルターを追加するか、スケジュールされたワークフローを使用してバッチ処理してください。
</Note>
**ベストプラクティス**:Search Records の後に[ブランチ](/l/ja/user-guide/workflows/capabilities/workflow-branches)を使用して、「見つかった」と「見つからない」のシナリオを処理します。
### Upsert Record
一致条件に基づいて、新しいレコードを作成するか、既存のレコードを更新します。 レコードが既に存在するかどうか確信が持てない場合に便利です。
<img src="/images/user-guide/workflows/upsert_double_identifier.png" style={{width:'100%'}} />
**設定**:
* 対象オブジェクトを選択
* どのフィールドがマッチングに使用できるかに注意してください:People には email、Companies には domain、任意のオブジェクトには ID、または Unique としてマークされた任意のフィールド。 以下のうち少なくとも 1 つは入力する必要があります。
* フィールドの値を入力します。 少なくとも 1 つの一意の識別子を必ず入力してください。
<Note>
**通常、一意の識別子を 1 つだけ追加するほうがマッチングはうまく機能します。** 例えば、以下のスクリーンショットでは、ドメインに基づいて会社を照合します。 ID は必ずしも必要ではありません。
</Note>
<img src="/images/user-guide/workflows/upsert_simple_identifier.png" style={{width:'100%'}} />
* 前の手順からのデータを使用してフィールドを埋める
**仕組み**:
1. 指定した条件に一致するレコードを検索します
2. 見つかった場合 → 既存のレコードを更新します
3. 見つからない場合 → 新しいレコードを作成します
**出力**:作成または更新されたレコードのデータは後続の手順で使用できます。
## フローアクション
### イテレータ
**前の手順から返されたレコード配列をループ**し、各レコードに個別にアクションを実行できます。
**設定**:
* 前のステップからレコードの配列を選択します (たとえば、format@@0の結果、format@@1のformat@@2ノードからformat@@3のトリガーを選択します)。 Code または Logic Function ステップがトップレベルの配列を返す場合は、その出力全体をループ処理するために **Whole list** オプションを選択します。
* ループ内の各レコードで実行するアクションを定義.
<Note>
- イテレータ内に複数のアクションを追加できます。
- イテレータ内でブランチを使用する場合は、各ブランチの最後のステップがイテレータに戻ってループを閉じるようにしてください。
</Note>
* `Current Item` フィールドにアクセス:現在処理中のレコードのフィールドを使用するには、**Iterator** ステップをクリックし、**Current item** を選択します。 そのレコードで使用可能なフィールドの一覧が表示され、後続のアクションで使用するために選択できます。 現在のアイテム全体を後続ステップに渡すには、**Use the whole item** を選択することもできます。
<VimeoEmbed videoId="1146577247" title="デモ動画" />
### フィルター
指定された条件に基づいてレコードをフィルタリングし、条件を満たすレコードのみを通過させます。
**設定**:
* フィルター対象のレコードを選択
* フィルタ条件と基準を定義
* 後続の手順に通過するレコードを設定
<Note>
1. **出力**:フィルターノードはデータを返しません—ゲートとして機能します。 条件を満たす場合、ワークフローは継続します。 満たさない場合、その分岐でワークフローは停止します。
2. `IS` 演算子は数値フィールドで使用できます。 これは `EQUAL` と同様に動作します。
</Note>
### 遅延
指定した期間、または特定の日時までワークフローの実行を一時停止します。
**遅延の種類**:
| タイプ | 説明 |
| -------- | --------------------- |
| **期間** | 指定した時間(日、時間、分、秒)待機します |
| **予定日時** | 特定の日時まで待機します |
**期間の設定**:
* 日、時間、分、秒を設定します
* 複数の単位を組み合わせます(例:2日と4時間)
**予定日時の設定**:
* 日付と時刻を選択します
* 前の手順の日付フィールドを参照できます(例:ミーティングの3日後にフォローアップ)
**ユースケース**:
* フォローアップメールを送信する前に24時間待機する
* 商談のクローズ日まで一時停止する
* 営業時間内にアクションを実行するようスケジュールする
<Note>
予定日時は過去に設定できません。 前の手順の日付フィールドを使用し、その日付がすでに過去の場合、ワークフローは失敗します。
</Note>
**制限とクレジット**:
* **最大期間の制限はありません**—分、日、週、さらに長い遅延を設定できます
* 期間に関係なく、Delay ノードの実行時に**1 クレジットを消費**します
* 待機中は**クレジットは消費されません**—5分の遅延も5日の遅延もコストは同じです
## コミュニケーションアクション
### メールを送信
ワークフローからメールを送信します。 テンプレート化されたグループメールに最適です。 メールは、メールボックスから送信するメールと同様の見た目になります。
ニュースレター(より豊かなフォーマットを必要とする)や自動メールシーケンスには適していません。
**前提条件**:設定 → アカウントでメールアカウントを追加
**設定**:
* 送信元のメールアカウントを選択
<Note>
自分の Twenty アカウントと同期されたメールボックスからのみメールを送信できます。 他のチームメンバーのメールボックス(例:アカウント所有者のメール)からの送信はロードマップにあります。
</Note>
以降のすべての手順で、パーソナライズのために前の手順の変数を参照できます。
* 受信者のメールアドレスを入力.
<Note>
現在は受信者は1名のみです。
</Note>
* 件名を設定.
* メッセージ本文を作成. リンクの書式設定、番号付きリストの作成、箇条書きリストの作成、添付ファイルの追加ができます。
<Note>
現在、HTML署名の追加はできません。
</Note>
### フォーム
ワークフロー実行中にフォームをプロンプトしてユーザー入力を収集します。 回答はその後、後続の手順で、入力に基づいてレコード作成、メール送信、その他のアクションの実行に利用できます。
<Warning>
**フォームは手動トリガー専用に設計されています。** 他のトリガーを持つワークフロー(レコード作成、更新など)では、ユーザーが期待する体験とは異なり、フォームにはワークフロー実行インターフェースからのみアクセス可能です。 通知センターは2026年にリリースされ、自動化されたワークフローのフォームを適切にサポートします。
</Warning>
**設定**:
* ユーザーに入力してもらうフィールドを設定します。 各フィールドについて、次を選択します。
* テキスト、数値、日付、特定のレコード、セレクトフィールドのいずれかのタイプ。 すべてのオブジェクトのフィールドは選択可能です。
* ラベル
* `Placeholder` のデフォルト値(任意)
* フォームのタイトルを編集
**出力**:フォームレスポンスが後続の手順で使用可能
**例**: "クイックリード" ワークフローは、すべてのワークスペースでデフォルトで使用できます。コマンドメニューの `Cmd+K` で利用できます。
**フォームの記入方法**:
* コマンドメニュー「Cmd+K」から手動ワークフローをトリガーする
* サイドパネルに表示されるフォームに入力し、`Submit` をクリックします。
<Note>
フィールドを必須にすることはできません。
</Note>
<VimeoEmbed videoId="1147277989" title="デモ動画" />
## 統合アクション
### コード
ワークフロー内でカスタムJavaScriptを実行します。
内部的には、それぞれの Code アクションは独自の **ロジック関数** によって支えられています。これは Twenty プラットフォーム上で実行されるサーバーサイドの TypeScript 関数です。 Code アクションを追加すると、Twenty はそのステップ専用のロジック関数を作成し、そのエディタをインラインで表示します。そのため、記述したコードはワークフローと一体となって存在します。
**設定**:
* 前の手順からの変数にアクセス. 変数の名前を動的に編集できます。
<VimeoEmbed videoId="1147281795" title="デモ動画" />
* エディタでJavaScriptコードを記述
* 後続の手順で使用するための変数を返す
* ステップ内でコードを直接テスト
<Note>
コードで外部のAPIキーを使用する必要がある場合は、関数本体に直接入力する必要があります。 他の場所でAPIキーを設定したり、ロジック関数で参照したりすることはできません。
</Note>
<Tip>
**配列を扱っていますか?** 外部システムや前の手順からの配列は、文字列として渡される場合があります。 配列の扱いの詳細については、[Code アクションで配列を扱う](/l/ja/user-guide/workflows/how-tos/advanced-configurations/handle-arrays-in-code-actions)を参照してください。
</Tip>
<Tip>
コードエディタ右上の四角いアイコンをクリックすると全画面表示になります — デフォルトのエディタ幅には制限があるため便利です。
</Tip>
#### ワークフロー間でロジック関数を再利用する
インラインの Code アクションは単発のロジックには最適ですが、その中に保持されるコードはその 1 つのステップ専用のものです。 複数のワークフロー間で同じロジックを共有したい場合や、アプリ内でバージョン管理されたソースとして維持したい場合は、各 Code アクションにコードをコピーペーストするのではなく、**再利用可能なロジック関数** を定義します。
ロジック関数は、アプリ内で一度だけ(SDK の `defineLogicFunction` を使用して)定義され、`workflowActionTriggerSettings` を追加することでワークフロービルダーに公開されます。 アプリがインストールされると、その関数は組み込みアクションと並んで、ワークフロービルダー内で 1 つのアクションとして表示されます。 それを選択すると、宣言した入力スキーマから生成された入力フィールド(他のアクションと同様に変数ピッカー付き)が表示され、共有コードが実行されます。インラインの JavaScript は不要です。
| | コードアクション | 再利用可能なロジック関数 |
| ---------- | --------------------------------- | -------------------------- |
| **コードの所在** | インラインエディタで記述され、1 つのワークフローステップに紐づく | アプリ内で定義され、ソース管理でバージョン管理される |
| **再利用性** | ステップごとにコピー&ペースト | 任意のワークフローでアクションとして追加可能 |
| **入力** | エディタ内で接続された変数 | 宣言した入力スキーマからレンダリングされるフィールド |
| **最適な用途** | 手早く記述できる、ワークフロー固有のロジック | 複数のワークフローで使用される共有ロジック |
両者は同じロジック関数ランタイム上で実行されるため、インラインで試作した Code アクションは、最小限の変更で再利用可能なロジック関数へ昇格させることができます。
<Tip>
ロジック関数を定義し、それらをワークフロービルダーに公開する方法に関する開発者向けリファレンスについては、[Logic Functions](/l/ja/developers/extend/apps/logic/logic-functions) を参照してください。特に **Exposing a function as an AI tool or workflow action** セクションと `workflowActionTriggerSettings` を確認してください。
</Tip>
### HTTPリクエスト
ワークフローの一部として外部APIにリクエストを送信します。
<img src="/images/user-guide/workflows/http_action.png" style={{width:'100%'}} />
**設定**:
* APIエンドポイントURLを入力. 前の手順のパラメーターを使用できます。
* HTTPメソッドを選択(GET, POST, PUT, PATCH, DELETE)
* 必要なヘッダと値を追加
* 構造プレビューのためにサンプルレスポンスを提供
## AI アクション
### AI エージェント - 近日公開
ワークフロー内でAIエージェントを実行し、インテリジェントなタスクを実行します。
**設定**:
* **エージェント**:既存のAIエージェントを選択するか、デフォルトのエージェントを使用します
* **プロンプト**:AIエージェントへの指示を作成します
* プロンプト内で前の手順の変数を参照します
**AI エージェントでできること**:
* データを分析・要約する
* レコードを分類・カテゴリ化する
* テキストコンテンツを生成する
* データに基づいて意思決定する
* ツールを使って CRM データと対話する
**出力**:AIエージェントの応答は後続の手順で使用できます。 エージェントに構造化された出力スキーマがある場合、応答はその形式に従います。
<Note>
AIエージェントのアクションは、使用するAIモデルに応じてワークフロークレジットを消費します。 詳細は[ワークフロークレジット](/l/ja/user-guide/workflows/capabilities/workflow-credits)を参照してください。
</Note>
<Note>
AIエージェントはロールベースの権限に従います。 **設定 → メンバー → ロール** でエージェントに特定のロールを割り当て、アクセスできるデータを制御できます。 詳細は[権限](/l/ja/user-guide/permissions-access/capabilities/permissions)を参照してください。
</Note>

View File

@@ -0,0 +1,66 @@
---
title: ワークフローのブランチ
description: ワークフロー内で並列パスと条件ロジックを作成します。
---
ブランチを使用すると、ワークフローを複数のパスに分割でき、データに基づいて同時に、または条件付きで実行できます。
<img src="/images/user-guide/workflows/branches.png" style={{width:'100%'}} />
## ブランチの仕組み
1つのノードから複数の接続を作成すると、各パスがブランチになります。 既定では、**すべてのブランチは並列に実行**され、互いを待ちません。
## ブランチの作成
### 新しいブランチを追加
1. **ワークフローのメインキャンバスを右クリック**(既存のノード上ではありません)
2. **ノードを追加** をクリック
3. 新しいブランチのノードタイプを選択
4. 前のステップの下部から、この新しいアクションの上部へ矢印をドラッグします
5. 同じノードからさらにブランチを追加するには、これを繰り返します。
<Note>
各ブランチは独立しています。 ブランチを追加しても、そのノードからの他の既存のパスには影響しません。
</Note>
### ビジュアルレイアウト
ブランチはワークフローエディター上で並列のパスとして表示されます。 実行に影響を与えることなく、ノードをドラッグしてビジュアルレイアウトを並べ替えることができます。
## 条件付きブランチ
既定ではすべてのブランチが実行されるため、どのパスを実際に実行するかを制御するには **Filter** ノードを使用します:
| ブランチ | フィルター条件 | アクション |
| ---- | ----------- | ------------- |
| A | ステージ = "受注" | お祝いのメールを送信 |
| B | ステージ = "失注" | フォローアップタスクを作成 |
| C | ステージ = "交渉" | マネージャーに通知 |
1. トリガーまたはアクションからブランチを作成する
2. 各ブランチの最初のステップとして **Filter** ノードを追加する
3. 各 Filter ノードを相互排他的な条件で設定する
4. 各 Filter の後にアクションを追加する
フィルター条件を満たしたブランチだけが実行を継続します。
## ブランチの統合
**ブランチは自動的には統合されません。** 各ブランチは終了するまで独立して実行されます。 この点の取り扱いは柔軟に設計できます:
* **オプション1: ブランチを分離したままにする**
各ブランチがそれぞれのフォローアップアクションを独立して処理します。 ブランチを統合する必要がない場合の最も簡単な方法です。
* **オプション2: ブランチを手動で統合する**
ワークフローを作成する際、複数のブランチを同じ下流のアクションに手動で接続できます。 各ブランチの末端から共通のノードへ矢印をドラッグするだけです。
<Note>
実行を一時停止するために [Delay](/l/ja/user-guide/workflows/capabilities/workflow-actions#delay) ノードを使用できますが、現在は「別のブランチが終了するまで」待機するように設定することはできません。
</Note>
## 関連
* [ワークフローでブランチを使用する方法](/l/ja/user-guide/workflows/capabilities/use-branches-in-workflows) - ステップバイステップのガイド
* [ワークフローアクション](/l/ja/user-guide/workflows/capabilities/workflow-actions) - Filter を含む利用可能なアクション

View File

@@ -0,0 +1,75 @@
---
title: ワークフロークレジット
description: ワークフロークレジットの消費と管理を理解する。
---
ワークフロークレジットは、Twentyでの自動化をサポートします。 その仕組みを理解することで、コストを最適化し、自動化予算を効果的に管理できます。 その仕組みを理解することで、コストを最適化し、自動化予算を効果的に管理できます。
## クレジット配分
ワークフロークレジットは、プランの種類ではなく、請求サイクルに基づいて割り当てられます:
| 請求サイクル | クレジット |
| --------------- | ----------- |
| **月額サブスクリプション** | 月あたり5クレジット |
| **年額サブスクリプション** | 年あたり50クレジット |
<Note>
標準的な自動化には、月間5クレジットで十分に余裕があります。 一般的なワークフローの利用で、この上限を超えるチームはほとんどありません。 追加のクレジットが主に必要になるのは、高度な Code アクションや AI 搭載ワークフローの場合です。
</Note>
## クレジット消費の仕組み
ワークフローは実行時にクレジットを消費し、それを作成する際には消費されません。 各ワークフローアクションはその複雑さに応じてクレジットを消費します。 各ワークフローアクションはその複雑さに応じてクレジットを消費します。 各ワークフローアクションはその複雑さに応じてクレジットを消費します。
### アクションタイプ別クレジット消費
* **基本的な内部操作**: 非常に低いクレジット消費
* レコードを検索
* レコードを作成
* レコードを更新
* レコードを削除
* フォームアクション
* **複雑な操作**: 高いクレジット消費
* コードアクション (JavaScript実行)
* 外部サービスへの HTTP リクエスト
* **AI 機能**: 高いクレジット消費
* AI エージェントのアクションは、使用する AI モデルに応じてクレジットを消費します
* より複雑なプロンプトや長い出力ほど、より多くのクレジットを使用します
* **Delay アクション**: クレジット消費は最小限
* Delay ノードは実行時に**1クレジット**を消費します
* **待機期間中はクレジットは消費されません**
* 5分の遅延も5日の遅延もコストは同じです
### リアルタイム控除
ワークフローが実行されると、クレジットはリアルタイムで控除されます。 つまり: つまり: つまり:
* ドラフトのワークフローはクレジットを消費しません
* アクティブで実行中のワークフローだけがクレジット配分を使用します
* 失敗したワークフローでも、完了したステップに対してはクレジットが消費されます
## クレジットの管理
### クレジット使用の確認
1. **設定 → 請求** へ移動
2. 現在のクレジット消費と残高を確認
3. 消費パターンを監視してワークフローを最適化
### 追加クレジットの購入
プランのクレジット割り当てを超える場合は:
1. **設定 → 請求** へ移動
2. 追加クレジットを購入するオプションをクリックします。 さまざまなサイズのパッケージが用意されています。 さまざまなサイズのパッケージが用意されています。
3. クレジットは現在の残高に追加されます
## ベストプラクティス
* **バッチ処理**: 効率的に一括操作やイテレータアクションを利用して、個々のアクション呼び出しを削減します
* **手動トリガーの最適化**: 手動トリガーでは、単一のワークフロー実行で複数のレコードを処理するために、`Bulk` の可用性を選択してください
* 効率性のためにコードアクションを最適化

View File

@@ -0,0 +1,93 @@
---
title: ワークフロー実行
description: ワークフローの実行を監視および管理します。
---
## 実行について
**実行**は、ワークフロー実行の記録です。 レコードイベント、スケジュール、手動操作、またはWebhookなどでワークフローがトリガーされるたびに、新しい実行が作成されます。
## 実行の表示
### ワークフローエディタから
1. 監視したいワークフローを開きます
2. 右側の**実行**パネルをクリックします
3. 最近の実行とそのステータスの一覧を確認します
### ワークフロー実行ビューから
1. サイドバーの**ワークフロー実行**に移動します
2. すべてのワークフローにわたる実行を表示します
3. ステータス、ワークフロー、日付でフィルタリングします
## 実行ステータス
| ステータス | 説明 |
| ------- | ------------------------------------------ |
| **実行中** | ワークフローが現在実行中です |
| **完了** | ワークフローが正常に完了しました |
| **失敗** | ワークフローでエラーが発生し、停止しました |
| **待機中** | ワークフローが一時停止しています(例:遅延アクションの待機中、フォーム送信の待機中) |
## 実行の詳細
任意の実行をクリックすると、次を確認できます:
* **ステータス**:実行の現在の状態
* **開始時刻**:実行が開始された時刻
* **所要時間**:実行に要した時間
* **トリガーデータ**:ワークフローを開始した入力データ
* **ステップの出力**:各ステップから返されたデータ
* **エラーメッセージ**:実行が失敗した場合に、何が問題だったか
## ステップごとの実行
各実行では、ワークフロー内での進行状況を表示します:
1. どのステップが正常に完了したかを確認します
2. 失敗が発生した箇所を特定します
3. ステップ間で受け渡されたデータを表示します
4. ステップの入力と出力を確認して問題をデバッグします
## エラーハンドリング
実行が失敗したとき:
1. 失敗した実行を開きます
2. 失敗の原因となったステップを特定します
3. エラーメッセージで詳細を確認します
一般的な問題:
* 必須フィールドの欠落
* 無効なデータ形式
* 外部 API エラー
* 権限に関する問題
## ワークフローの再実行
実行が失敗した場合、次のことができます:
* 根本的な問題を修正し、次のトリガーを待つ
* 手動ワークフローの場合、同じデータまたは更新したデータで再度トリガーする
* 今後の失敗を防ぐためにワークフローのロジックを見直す
## パフォーマンスのヒント
### 実行履歴の管理
* 実行は履歴の参照のために保持されます
* 非常に古いランニングは自動的にアーカイブされることがあります
* 記録を保持する必要がある場合は実行データをエクスポートします
### ベストプラクティスの監視
* 新しいワークフローをアクティブにした後に定期的にチェック
* パターンを識別するための実行の確認に失敗しました
## 関連
* [ワークフローのトリガー](/l/ja/user-guide/workflows/capabilities/workflow-triggers)
* [ワークフローのアクション](/l/ja/user-guide/workflows/capabilities/workflow-actions)
* [ワークフローのトラブルシューティング](/l/ja/user-guide/workflows/how-tos/need-more-help/workflow-troubleshooting)

View File

@@ -0,0 +1,136 @@
---
title: ワークフロートリガー
description: ワークフローを開始するさまざまなトリガーについて学びましょう。
---
## トリガーについて
ワークフローは、常に自動化をいつ実行するかを定義する単一のトリガーで開始されます。
<img src="/images/user-guide/workflows/workflow_triggers.png" style={{width:'100%'}} />
<Tip>
**高度なオブジェクトにも対応しています!** 標準の CRM オブジェクト(People、Companies、Opportunities)に加えて、次のオブジェクトでもワークフローをトリガーし、アクションを実行できます:
* ワークスペースメンバー
* カレンダーイベント
* メッセージ(メール)
* タスク、ノート、その他多数のシステムオブジェクト
これにより、カレンダーイベントが作成された際にチームメンバーに通知したり、受信メールを自動処理したりするなど、強力な自動化が可能になります。
</Tip>
## レコードの作成
新しいレコードが選択されたオブジェクト(人物、会社、機会、または任意のカスタムオブジェクト)で作成されるときに、ワークフローを開始します。
**設定**:新しいレコードを監視するオブジェクトタイプを選択します。
<Note>
* このトリガーは、CSV、メールボックス、カレンダー同期、またはAPIによって作成されたレコードに最適です。
* **手動で作成されたレコードには推奨されません**: このトリガーでは、レコードが作成されるとすぐにワークフローが開始します。 Twenty UI はオンザフライで自動保存を提供しています(編集モードがなく、レコードを保存するための検証があります)。 ユーザーがすべての項目を入力する前にワークフローがトリガーされます。
手動で作成されたレコードでこのワークフローをトリガーするには、代わりにトリガー `Record is created or updated` を使用することを推奨します。
</Note>
## レコードの更新
既存のレコードに変更が加えられたときにワークフローを開始します。
**設定**:
* オブジェクトタイプを選択
* 変更を監視するフィールドをオプションで指定
## レコードの更新または作成
選択されたオブジェクトでレコードが作成または更新されたときに、ワークフローを開始します。
**なぜ重要か**:このトリガーが特に役立つのは、さまざまな方法で作成されたレコードが異なる動作をするためです。
* **API/CSV インポート**: レコードはすべてのフィールドが即座に入力されて作成されます。
* **手動作成**: レコードは最初に作成され、その後の更新でフィールドが追加されます。
**設定**:
* 監視するオブジェクトタイプを選択
* 変更を監視するフィールドをオプションで指定
* ワークフローは最初の作成時とその後のすべての更新時にトリガーされます。
## レコードの削除
オブジェクトからレコードが削除されたときにワークフローを開始します。
**設定**:削除を監視するオブジェクトタイプを選択します。
## 手動トリガー
ユーザーのアクションによってトリガーされたときにワークフローを開始します。 このトリガーには、`Cmd+K` メニューから、またはレコードを選択した後にトップナビバーに表示されるカスタムボタン経由でアクセスできます。
<img src="/images/user-guide/workflows/add_to_newsletter_button.png" style={{width:'100%'}} />
**可用性設定**: レコードの選択をワークフローでどのように扱うか選択します。
* **グローバル**: このワークフローをトリガーするためにレコードは必要ありません。 ワークフローは(任意のオブジェクトから)任意のコマンドメニュー`Cmd+K`からトリガーされ、入力として記録を使用しません。
**Single** と **Bulk** の可用性の場合、選択したレコードはワークフローに渡されます。 これは特定のオブジェクトに対して設定されており、ワークフローをトリガーする前に複数のレコードを選択できます。
* **シングル**: ワークフローはレコードが選択されているので、最初から最後まで実行されます。
<Note>
**ソフト上限: 100回/分**。 これを超えると、ワークフローは "Not Started" ステータスのままになり、バックグラウンドジョブによって、または別のワークフローがキューに入ったときに段階的に処理されます。 つまり、単一のトリガーで100件を超えるレコードを選択できますが、実行は遅くなります。
</Note>
* **一括**: ワークフローは一度実行され、レコード全体を入力として提供します。 つまり、このワークフローには [イテレーターアクション](/l/ja/user-guide/workflows/capabilities/workflow-actions#iterator) を含める必要があります。
<Note>
こちらはより高度で、ワークフローの実行回数を最適化したい人に最適です。
</Note>
<img src="/images/user-guide/workflows/manual_trigger.png" style={{width:'100%'}} />
**追加の設定**:
* 対象オブジェクトを選択(シングルと一括の可用性用)
* ワークフロートリガーのコマンドアイコンを選択
* ナビゲーションバープレースメントを設定(固定または未固定)
**アクセス方法**:
* `Cmd+K` メニューで手動ワークフローを見つけて起動
* トップナビゲーションバーのカスタムボタン(設定されている場合)
## 時間ベースのトリガー: スケジュール実行
指定された頻度でワークフローを開始します。
**設定**:
* 時間単位を選択(分、時間、日)
* 高度なスケジュール設定には、値を入力するか、カスタム cron 式を使用します
<Note>
**タイムゾーン**: スケジュールされたワークフローは **UTC** で実行されます。 日次スケジュールの時間を設定する際は、ローカル時間を UTC に変換してください。
</Note>
## 外部トリガー: Webhook
外部サービスからのGETまたはPOSTリクエストを受信するとワークフローを開始します。
<img src="/images/user-guide/workflows/webhook_trigger.png" style={{width:'100%'}} />
**設定**:
* ワークフローは一意の Webhook URL を提供します—これをコピーして、呼び出し先エンドポイントとして外部システムに追加してください。
* POST リクエストの場合、Twenty が想定するデータを認識できるよう、期待されるボディ構造を定義してください。 ここに、ワークフロー内の後続の処理で必要となる、受信するフィールドを追加してください。
* 認証の設定(近日対応)。
## 適切なトリガーの選び方
| ユースケース | 推奨トリガー |
| --------------- | ------------------- |
| 新規リードの処理が必要 | レコードの作成 |
| データ変更の同期が必要 | レコードの更新 |
| インポート/手動でのデータ処理 | レコードの更新または作成 |
| 削除後のクリーンアップ | レコードの削除 |
| ユーザー起点のアクション | 手動で起動 |
| 定期レポート | スケジュールで |
| 外部統合 | Webhook またはスケジュール実行 |

View File

@@ -0,0 +1,84 @@
---
title: ワークフローバージョン
description: ワークフローのバージョンとドラフトを管理します。
---
## バージョンについて
ワークフローを有効化するたびに、新しいバージョンが作成されます。 これにより、経時的な変更を追跡し、必要に応じて以前の設定に戻すことができます。
## バージョンの状態
| ステータス | 説明 |
| ----------- | ------------------- |
| **ドラフト** | 編集中、まだ公開されていない |
| **アクティブ** | トリガーに応答する稼働中のバージョン |
| **無効化済み** | 以前はアクティブだったが手動で停止 |
| **アーカイブ済み** | 履歴のために保存された過去のバージョン |
## ドラフトの操作
アクティブなワークフローを編集すると、変更は**ドラフト**として保存されます。 更新作業中も、アクティブなバージョンは引き続き稼働します。
編集が完了したら、次のいずれかを実行できます。
* **有効化**: ドラフトを新しいアクティブ版として公開します(以前のバージョンはアーカイブされます)
* **破棄**: ドラフトを削除し、現在のアクティブ版を維持します
## バージョン履歴
### 過去のバージョンを表示
1. ワークフローを開く
2. **バージョン** タブをクリック
3. タイムスタンプ付きですべての過去バージョンを確認
### バージョンの復元
1. 復元したいバージョンを見つける
2. 「**ドラフトとして使用**」をクリック
3. そのバージョンが新しいドラフトにコピーされます
4. 必要な更新を行う
5. 準備ができたら有効化する
## ベストプラクティス
### バージョン管理
* 本番運用の準備が整ってからのみ有効化する
* バージョン間の変更は意味のあるものに限定する
* ワークフロー名や説明の大きな変更は記録する
* 有効化する前にドラフトモードでテストする
### 変更のロールバック
* 新しいバージョンで問題が発生した場合は、前のバージョンを復元する
* バージョン履歴を使用して何が変わったかを追跡する
* 復元したバージョンは、有効化前に必ずテストする
## 一般的なワークフロー
### クイック編集
1. アクティブなワークフローに軽微な変更を加える
2. ドラフトモードでテストする
3. 新しいバージョンを有効化する
### 大幅な修正
1. 前のバージョンを出発点として使用する
2. ドラフトで大きな変更を加える
3. あらゆるシナリオを徹底的にテストする
4. 確信が持てたら有効化する
### ロールバック
1. 現在のバージョンの問題を特定する
2. 履歴から最後に正常に動作していたバージョンを見つける
3. 「**ドラフトとして使用**」をクリック
4. 有効化して以前の挙動を復元する
## 関連項目
* [ワークフロー入門](/l/ja/user-guide/workflows/overview)
* [ワークフローの実行](/l/ja/user-guide/workflows/capabilities/workflow-runs)