# Operational process coordination Operational processes at any organization, whether it is ensuring that [invoices are handled correctly](../../use-case-examples/improving-invoice-collection-through-intelligent-dispute-resolution/index.md), [power shutoffs are managed to avoid wildfire risk](../../use-case-examples/public-safety-power-shutoff-psps-scoping/index.md), or R\&D data is managed and leveraged efficiently and safely, require users to interface with a variety of source systems, resolve any conflicts among them, interact with specialized applications, make operational decisions, and record those decisions to improve the process and feed others downstream. Foundry’s [Data Connection](../../data-connection/overview/index.md) and [Ontology](../../ontology/overview/index.md) allow organizations to implement this pattern in days instead of months and continue to implement, customize, and maintain them safely and efficiently. ![Operational Process Coordination Pattern](../../../assets/589e50e456fb49f7221a17de911f9c33d644e4607d0d5984943fd2c6c2101321.jpg) ## Solution Consider any critical business process, whether it is ensuring that [invoices are handled correctly](../../use-case-examples/improving-invoice-collection-through-intelligent-dispute-resolution/index.md), [power shutoffs are managed to avoid wildfire risk](../../use-case-examples/public-safety-power-shutoff-psps-scoping/index.md), or R\&D data is managed and leveraged efficiently and safely. These disparate processes all share the same pattern: they require many different users and types of users to interact with a variety of source systems and other users in order to make operational decisions that are critical for the organization. Moreover, these processes evolve over time and the tools used need to evolve with them while remaining secure and maintainable. Yet, in practice, these processes are often implemented as custom software that is purpose-built to interact with a particular set of datasources, difficult to manage or update, siloed from other such software, and follows its own security model. Alternatively, the process is managed via spreadsheets and emails, which have technical limitations, are error-prone and insecure, and are difficult to manage and collaborate on. In Foundry, organizations instead implement the pattern below to integrate all of the relevant data sources into an ontology, from which [Workshop](../../workshop/overview/index.md) apps are used to build custom apps which write back to the ontology and external systems. All of this is governed safely using Foundry’s Platform Security Model (often across multiple organizations such as vendors), and can be easily maintained and improved on via Foundry’s version control systems. ## Key elements ***Action Inbox*** An **Action Inbox** in [Workshop](../../workshop/overview/index.md) which allows **different users** to be **assigned tasks**, **view and explore** the key aspects of the ontology, and **take actions to make real-world decisions**. For example, in a process for doing [Invoice Dispute Resolution](../../use-case-examples/improving-invoice-collection-through-intelligent-dispute-resolution/index.md), invoices are assigned to users in the correct department, where they review the customer service actions that are taken, see potential causes of injury, and submit a clear explanation for the invoice, which is shared back with the customer downstream of the application. Related products: * [Workshop](../../workshop/overview/index.md) * [Actions](../../action-types/overview/index.md) * [Functions on Objects](../../functions/overview/index.md) ***Operational Process [Ontology](../../ontology/overview/index.md)*** Underlying the Action Inbox is an **[Ontology](../../ontology/overview/index.md)**, which models the operational process as **objects** with **properties** and **relations. For example:** * Tasks have assignees, creation and assignment times, priorities, and statuses * Workflows contain tasks and model sequential steps in a process Users are available in [Workshop](../../workshop/overview/index.md) automatically and do not need to be modeled in the ontology, but can be if it is helpful to associate them with additional properties such as department or location. Related products: * [Ontology](../../ontology/overview/index.md) * [Object Explorer](../../object-views/overview/index.md) ***Subject Matter [Ontology](../../ontology/overview/index.md)*** In addition to the functional ontology for the Action Inbox, there is a **digital twin** of the subject matter, which serves as the **single source of truth** that users reference to make their decisions. The **objects**, **properties**, and **relations** will differ depending on the use case, but are typically shared across many use cases and are visualized within [Object Explorer](../../object-views/overview/index.md) views (object-centric), [Quiver](../../quiver/overview/index.md) (charting and dashboarding), or [Vertex](../../vertex/overview/index.md) (network analysis). For example, for Public Safety Power Shutoff (PSPS) Scoping, objects would include assets like transformers and circuits, weather threshold breaches, and grid configurations. Related products: * [Ontology](../../ontology/overview/index.md) * [Object Explorer](../../object-views/overview/index.md) ***Decision writeback*** Actions taken in the Action Inbox trigger **writeback** to the process ontology (e.g. creating, updating, or reassigning tasks), but more importantly to the subject matter ontology, where it updates the digital twin and then writes back to **external sources**. For example, for Public Safety Power Shutoff (PSPS) Scoping, decisions made in the inbox mark customers (objects in Foundry) as unsuccessfully contacted to be recontacted later as well as push notifications to the external automated message broadcast system. Related products: * [Ontology](../../ontology/overview/index.md) ***Business logic and automation*** Logic that drives the Action Inbox is often implemented in pipelines, e.g. determining which actions to map to which users or prioritizing which actions to implement first. These often leverage models created and managed in [Foundry Machine Learning](../../model-integration/overview/index.md). For example, [Invoice Dispute Resolution](../../use-case-examples/improving-invoice-collection-through-intelligent-dispute-resolution/index.md) uses upstream logic to determine which department is best suited to handle a given inquiry. Related products: * [Code Repositories](../../code-repositories/overview/index.md) * [Code Workbook](../../code-workbook/overview/index.md) ## Requirements Regardless of the Pattern used, the underlying data foundation is constructed from pipelines and syncs to external source systems. ***Data integration pipelines*** Data integration pipelines, written in a variety of languages including SQL, Python, and Java, are used to integrate datasources into the subject matter ontology. ***[Data Connectors](../../data-connection/overview/index.md)*** Foundry can sync data from a wide array of sources, including FTP, JDBC, REST API, and S3. Syncing data from a variety of sources and compiling the most complete source of truth possible is key to enabling the highest value decisions. ***(Optional) SAP and Salesforce Connector*** Many organizational processes rely on SAP and Salesforce data, and Foundry has out-of-the-box connectors and integration pipelines for both sources that ingest and create ontologies in just a few clicks. [Invoice Dispute Resolution](../../use-case-examples/improving-invoice-collection-through-intelligent-dispute-resolution/index.md), for example, uses both of these sources. ## Use cases implementing this pattern * [Driving revenue through integrated pricing](../../use-case-examples/driving-revenue-through-integrated-pricing/index.md) * [Improving customer satisfaction and retention through intelligent task management](../../use-case-examples/improving-customer-satisfaction-and-retention-through-intelligent-task-management/index.md) * [Improving invoice collection through intelligent dispute resolution](../../use-case-examples/improving-invoice-collection-through-intelligent-dispute-resolution/index.md) * [Increasing client engagement through integrated campaign management](../../use-case-examples/increasing-client-engagement-through-integrated-campaign-management/index.md) * [Optimizing production with ERP data across the supply chain](../../use-case-examples/optimizing-production-with-erp-data-across-the-supply-chain/index.md) * [Public safety power shutoff (PSPS) scoping ](../../use-case-examples/public-safety-power-shutoff-psps-scoping/index.md) * [Reduce rail disruptions through intelligent maintenance prioritization](../../use-case-examples/reduce-rail-disruptions-through-intelligent-maintenance-prioritization/index.md) * [Reducing over- and under-payments to health care providers](../../use-case-examples/reducing-over-and-under-payments-to-health-care-providers/index.md) Want more information on this use case pattern? Looking to implement something similar? [Get started with Palantir. ↗](https://www.palantir.com/contact/get-started/)