Loading
目次
絞り込み条件を選択

          結果がありません
          結果がありません
          検索のヒントをいくつかご紹介します

          キーワードの入力ミスがないか確認する。
          より一般的な検索語を使用する。
          絞り込み条件を減らして、検索範囲を広げる。

          Salesforce ヘルプ全体を検索
          Dynamic Revenue Orchestrator as the Integration Orchestration Layer

          Dynamic Revenue Orchestrator as the Integration Orchestration Layer

          CPQ integrations are typically point-to-point, with direct connections from CPQ to an Enterprise Resource Planning (ERP) system, a billing system, or a provisioning platform. Each connection is independently maintained, monitored, and subject to breaking when there are changes. As part of the Revenue Management migration, treat the integration landscape as a dedicated workstream. Take the opportunity to rethink the architecture rather than just remap the connections.

          In a traditional CPQ environment, when an order is placed, middleware or custom code must determine the required downstream actions, such as provisioning the product, notifying the ERP, triggering billing, and updating the provisioning platform. That logic typically lives across multiple point-to-point integrations that can be difficult to maintain over time. Dynamic Revenue Orchestrator (DRO) replaces this approach by acting as the single orchestration layer where all downstream operations are coordinated and monitored.

          Orchestration Layer Capabilities

          DRO acts as the central coordination layer for post-order fulfillment.

          • A single place to define the required actions after an order is placed, including provisioning, fulfillment, billing triggers, and ERP updates, and their sequence.
          • A visual canvas where the orchestration plan is visible to operations teams. Rather than logic buried in middleware or custom Apex, the fulfillment flow is designed, monitored, and managed in one place.
          • Native integration points for downstream systems. Rather than each system needing its own custom integration to the Order record, DRO decomposes the commercial order into technical fulfillment tasks. Each task carries exactly the data that the downstream system needs in the structure it expects.
          • Every step in the fulfillment flow has a status. Jeopardy conditions, where a step is at risk of missing its Service Level Agreements (SLAs), are surfaced automatically. Operations teams can see the entire downstream picture from a single view without switching between systems.

          For companies that currently manage provisioning, ERP updates and billing triggers through separate integrations from CPQ, DRO represents a meaningful architectural improvement. This approach is relevant for telecommunications, technology services, and manufacturing companies where fulfillment involves multiple internal teams or third-party vendors. The complexity that was distributed across many connections is consolidated into a single, visible orchestration model.

          Practical Implication

          Consider a company selling a software subscription with these downstream dependencies.

          • An ERP that needs to recognize the revenue
          • A billing system that needs to initiate the invoice schedule, and
          • A provisioning platform that needs to activate the license.

          In CPQ, these dependencies typically require three separate integrations, each triggered by the Order record and handling amendments independently. In Revenue Management with DRO, the commercial order is placed at a time. DRO decomposes it into three orchestrated fulfillment tasks, one for each downstream system and each carrying the correct technical payload. If the order is amended, DRO reorchestrates the downstream tasks automatically. The operations team sees all three tasks, their status, and any jeopardy conditions on a single canvas. No middleware logic changes are required.

          ERP Integration

          ERP integration is one of the most impactful areas to address during migration.

          • In Revenue Management, Order and OrderProduct are standard Salesforce objects. ERP integrations that currently reference CPQ custom objects should be remapped to these standard objects as part of the migration.
          • For companies using DRO, ERP updates can be triggered as orchestrated fulfillment tasks rather than direct integrations. This approach simplifies the integration model and ensures that ERP updates are sequenced correctly within the broader fulfillment flow.
          • Remapping integration field identifiers such as Order IDs and Contract IDs is a key migration activity. Address this activity as an explicit workstream.
          • Use Invoice Management to streamline integration by transferring Invoice records from Revenue Management to your ERP system.

          Billing System Integration

          Billing system integration requires deliberate evaluation during migration.

          • If using a third-party billing system alongside CPQ, assess whether Revenue Management's native billing capabilities can replace it. Consolidating to a single platform simplifies the architecture significantly.
          • If retaining an external billing system, billing triggers can be modeled as DRO fulfillment tasks, giving the operations team visibility of billing initiation within the same orchestration canvas as provisioning and ERP.
          • Invoice and payment reconciliation workflows should be revalidated as part of the go-live acceptance criteria.

          Provisioning System Integration

          Provisioning integration is one of the areas where DRO delivers the most direct operational value.

          • Provisioning is where DRO's orchestration value is most directly felt. The commercial order describes the customer's purchase. DRO translates that into the technical specification the provisioning system needs.
          • For companies with complex product decomposition where a single commercial product requires multiple technical provisioning actions, DRO's decomposition mapping handles this natively, removing the need for custom translation logic in middleware.
          • Provisioning SLAs can be defined at the DRO task level, and jeopardy conditions are surfaced automatically when a task is at risk of missing its target.
           
          読み込み中
          Salesforce Help | Article