ワークフロー公開プレビュー

Stripe ダッシュボードには Workflows のビジュアルビルダーが用意されており、順番に実行される一連のアクションを定義することで、タスクやプロセスを自動化できます。Workflows は複数ステップのプロセスに最適で、複数の Stripe プロダクト間で互換性があるため、プロセスの合理化、ビジネスルールの適用、手作業の削減が可能になります。

Each workflow consists of a trigger and a series of steps that run in order. A step is either an action or a condition. A workflow is made up of the following components:

ワークフローは、トリガーと条件に基づいて一連のアクションを順番に実行することで、タスクを自動化します。複数のワークフローが同じトリガーイベントを共有する場合、各ワークフローは、独自に定義されたステップとビジネスロジックに従って独立して実行されます。

アクティブなワークフローと非アクティブなワークフロー

ワークフローをアクティブ化、非アクティブ化、または削除できます。ワークフローを非アクティブにすると、Stripe はワークフローを無効と見なし、トリガーに応答しなくなります。非アクティブなワークフローは、いつでも再度アクティブにできます。一度に最大 6 つのアクティブなワークフローを維持でき、アクティブなワークフローと非アクティブなワークフローの両方を含む合計 20 のワークフローを持つことができます。

ワークフローが 20 個ある場合、別のワークフローを作成することはできません。アクティブなワークフローが 6 つあり、別のワークフローをアクティブにする場合は、まず既にアクティブなワークフローを非アクティブにする必要があります。

トリガー

Workflows are started by Stripe API events. Each workflow has one trigger, and it’s always the first step of a workflow. The trigger provides data about the event. This data is passed into the workflow so subsequent steps can use it. After a trigger fires and provides its data, the workflow moves on to perform its actions using that data.

If you want to trigger a workflow related to a customer, these triggers can apply to you:

If you’re using Stripe to accept payments (such as Stripe Checkout or the CheckoutSessions API), these triggers can apply to you:

If you’re using Stripe to accept async payment methods, such as bank transfers and BNPL (which requires additional time to confirm payment details), these triggers can apply to you:

If you want to trigger a workflow based on the outcome of money movement or whether a charge succeeds or fails, the following triggers can apply to you. Note that most Stripe integrations use Checkout or PaymentIntent events (for example, Checkout session is complete) instead of directly listening to charge events.

サポートされているトリガー

ワークフローは、Stripe v1 と v2 の両方のトリガーとしてほとんどのイベントをサポートします。サポートされていないイベントは、ダッシュボードでは使用できません。

Connect をトリガーと共に使用する

Stripe Connect platforms and marketplaces can trigger workflows using events from the platform account, but not from connected accounts. This means you can trigger workflows for something in your platform account, such as when a payment succeeds, but you can’t trigger workflows directly from events that occur in your connected accounts.

アクション

An action is task that is performed automatically based on data from the trigger or from previous steps. Every workflow must have at least one action, and most workflows contain several actions in sequence.

一般的なアクションには、次のようなものがあります。

• 顧客を更新する: 追跡やレポート作成の目的でメタデータフィールドを使用してカスタムデータを追加するなど、既存の顧客の詳細を変更します。
• 請求書を取得する: ステータスなど、特定の請求書の最新の詳細を取得します。これは通常、請求書の更新や現在の状態に基づく意思決定など、後のステップで使用されるデータを収集するために使用されます。
• サブスクリプションを取得するを参照してください。プランや請求サイクルなど、顧客のサブスクリプションの最新の詳細を取得します。これは通常、サブスクリプションの更新や条件ロジックの適用など、後のステップで使用するサブスクリプションデータを収集するために使用されます。
• サブスクリプションを更新する: プランの変更、請求サイクルの更新、割引の適用など、アクティブなサブスクリプションを変更します。

ワークフローステップは、トリガーイベントの後に開始され、順番に実行されます。各ステップは、動的フィールドを使用して、トリガーおよび前のステップからの情報にアクセスできます。これらのフィールドはスマートプレースホルダーとして機能し、ワークフローの進行に合わせてリアルタイムのデータが自動的に入力されます。このシステムにより、各ステップがワークフローを流れるデータに適応し、柔軟で応答性の高いワークフローが可能になります。

Actions operate on the most recent state of an object at the time the action runs. This means if an object changes between the initial trigger and a subsequent action, the action will affect the latest version of the object. Dynamic references, however, use the state of the object at the time that it was last retrieved.

サポートされているアクション

Workflows は、Stripe v1 と v2 の両方でほとんどの API アクションをサポートしています。サポートされていないアクションは、ダッシュボードでは使用できません。現在、すべての Stripe リストアクションはアクションとしてサポートされていません (たとえば、不審請求の申し立てのリストアクションなど)。

Connect をアクションと共に使用する

Stripe Connect platforms and marketplaces can use actions in workflows through the platform account, but not through connected accounts. This means your workflow can perform actions such as refunding a payment or updating a customer in your platform account, but it can’t directly perform actions in your connected accounts

ワークフローに固有のアクション

以下はワークフローに固有のアクションであり、ダッシュボードのビジュアルビルダーを使用してのみ使用でき、パブリック API の一部ではありません。

条件

条件を使用すると、ワークフローにロジックを追加して、ワークフローを続行するかどうか、およびどのように処理すべきかを制御するルールを定義できます。条件は、通常、トリガーまたはそれ以前のステップからのデータを評価するチェック機構です。使用方法に応じて、条件によって、ワークフローを実行するかどうか、続行するかどうか、またはどのパスをたどる必要があるかが決まります。使用できる条件は、ワークフローが参照する予定のデータによって異なります。

トリガー条件

トリガー条件は、ワークフローを開始するイベントを絞り込みます。ワークフローは、トリガー条件が true の場合にのみ実行されます。これらは、ワークフローを特定のユースケースに絞り込む場合 (たとえば、特定の金額を超える支払いが成功した場合にのみワークフローを実行する、など) に便利です。その主な目的は、ワークフローを実行する必要があるかどうかを判断することです。

ダッシュボードでのトリガー条件の設定

仕組みは以下のとおりです。

1. Stripe アカウントでイベントが発生します。
2. トリガー条件は、このイベントが特定の基準を満たしているかどうかをチェックします。
3. 条件が満たされると、ワークフローが開始されます。満たされない場合、何も起こりません。

1 つの条件を作成して、1 つのトリガーに適用できます。以下に例を挙げます。

また、複数の条件を作成してトリガーに適用することもできます。以下に例を挙げます。

条件は、ワークフローを特定の状況に絞り込むのに役立ち、ワークフローの精度を調整するのに役立ちます。

ステップとしての条件

トリガー条件に加えて、ワークフロー内に条件ステップを追加できます。これらの条件ステップにより、ワークフロー開始後の動作を制御できます。

たとえば、特定の条件が満たされているかどうかをチェックし、ワークフローを続行する必要があるかどうかを判断するための条件を、ステップとしてワークフローに追加できます。条件ステップを追加することで、値を評価し、続行するかどうかを決定できます。条件が true の場合、ワークフローは次のステップに進みます。ただし、false の場合、ワークフローは停止し、成功としてマークされます。このアプローチを使用して、アクション完了後に結果を確認します。

分岐条件

条件ステップの別の例は、条件を分岐として使用することです。これにより、ワークフロー内に決定ポイントを導入し、指定した条件に基づいて複数のパスに分岐させることができます。条件ステップから複数のパスを構築して、ワークフローがさまざまなパスをたどり、さまざまな条件に基づいてさまざまなアクションを実行するようにできます。このアプローチは、顧客の国や購入金額に基づいて異なるメールをアカウントチームごとに送信するなど、複数のシナリオを処理する場合に使用します。

2 つの分岐を作成する条件の例:

条件を追加して、2 つ以上の分岐を作成することもできます。これにより、ワークフローは 1 つの決定ポイントから複数のシナリオを処理できます。

3 つの分岐を作成する条件の例:

各条件は、ビジュアルビルダーで左から右の順に評価されます。ワークフローは、最初に一致したパスをたどり、他のパスはスキップします。トリガー条件は、ワークフローを実行する必要があるかどうかを決定します。条件ステップは、ワークフローの開始後の動作を制御し、続行するか、別のパスに分岐するかを決定します。

In many cases, the same condition logic might used at the trigger or step level. Where you apply a condition depends on what you want to control, whether the workflow must start, whether it must continue after starting, or which path it must take during its run.

Additional built-in features

• Recursion detection: To prevent the creation of unintentional infinite loops or runaway workflows, Workflows automatically identifies and stops such recursions. For example, consider a workflow triggered by a customer event, that also includes an action to update the customer’s information. Performing this action generates another customer updated event, which could re-trigger the same workflow, leading to a potential infinite loop. To protect against this, Workflows allows recursion to occur only once; however, if it happens more than once the workflow ends with an error.

• 自動再試行: 信頼性を向上させるため、Workflows では、再試行可能なエラーが発生したアクションを自動的に再試行します。つまり、一時的な問題が原因でアクションが失敗した場合、ワークフローは手動による介入を必要とせずにアクションの再実行を試みます。これにより、一時的なエラーが原因でワークフローが失敗することがなくなり、スムーズで一貫性のあるワークフロー実行が促されます。

• Idempotency: Idempotency ensures that actions are only run once, even if the same request is submitted multiple times. Workflows automatically handles duplicate requests, preventing unintended repeated actions. This safeguard helps ensure consistency when network issues or errors might lead to retrying requests.

• Observability: Observability helps you monitor, troubleshoot, and resolve issues within your workflow quickly. Workflows provides the following to help with observability:

  • Run status: Each workflow can have one of three statuses, “running”, “succeeded”, or “failed”. In the case of a failure, a detailed error message is provided to help you quickly diagnose and resolve the issue.
  • Run details: You can inspect individual workflow runs to view the exact run path, including which steps were executed, the parameters used, and any errors encountered. This visibility allows you to quickly pinpoint which step in your workflow caused an error as well as understand the path an execution took.