Integration Connectors and Automation Guide

Configure integrations and automate data movement

Integration Connectors and Automation Guide explains how to set up and manage the integration patterns that connect Yarken to external systems.

Use this guide when you need to configure connections, choose the right connector type, build pipelines or recipes, map external fields into Yarken, automate recurring data movement, or support custom integration needs.

Before you begin

Before creating an integration, confirm the following:

The source system you want to connect to
The data or event Yarken needs from that system
Whether Yarken needs to retrieve data, send data, trigger an action, or both
The authentication method required by the source system
The permissions or service account required
Whether the data should be ingested once, on a schedule, or when an event occurs
Whether a data mapping template is required
Which Yarken model, report, pipeline, recipe, dashboard, or workflow will use the data

Core setup flow

Most integrations follow this flow.

Choose the source system
Select the connector type
Create or authorize the connection
Configure the trigger, schedule, or source location
Select the data or event to retrieve
Map external fields into Yarken fields
Test the integration
Review the results in Yarken
Enable the pipeline or recipe
Monitor execution and resolve errors as needed

Step 1: Choose the integration pattern

Start by selecting the best integration approach.

Use a pre-built connector when Yarken already supports the source system.

Use a universal connector when the system has an API but no pre-built connector.

Use a database connector when structured data is available through direct database access.

Use file exchange when the system can export files to SFTP or cloud storage.

Use a custom action when an existing connector is missing one specific operation.

Use a custom connector when the integration needs to be reusable, governed, versioned, or shared across teams.

Step 2: Create a connection

A connection stores the credentials and configuration Yarken needs to communicate with the external system.

Depending on the source system, the connection may require:

OAuth authorization
Service principal details
API key or token
Username and password
Database credentials
Tenant ID or domain details
File storage path
SFTP or cloud storage credentials

After the connection is created, Yarken can use it in supported pipelines, recipes, reports, or automation workflows.

Step 3: Configure the connector

A connector defines how Yarken communicates with the source system.

For a pre-built connector, select the supported connector and configure the required fields.

For a universal connector, provide the API details, request method, authentication, endpoint, headers, parameters, request body, and response handling as required.

For a database connector, configure the database type, host, port, database name, authentication, and query or table access.

For file exchange, configure the storage provider, folder path, file pattern, schedule, and mapping template.

For custom connectors, configure the packaged triggers, actions, authentication, and schemas defined for that connector.

Step 4: Define triggers and actions

Triggers start a workflow when something happens.

Examples include:

A file is added to cloud storage
A new ticket is created
A license record is updated
A new invoice is available
A scheduled run starts

Actions perform work in a connected system.

Examples include:

Create a record
Update a record
Post a message
Write a row
Open a ticket
Send data to another system

Use triggers and actions when the integration needs to automate a workflow, not only retrieve data.

Step 5: Build a pipeline or recipe

Use a pipeline when the integration involves recurring data ingestion or processing.

Pipelines are useful for scheduled data movement, file ingestion, cloud usage data, license usage data, spend data, budget data, and other repeatable data loads.

Use a recipe when the integration is a focused automation built from one trigger and one or more actions.

Recipes are useful for event driven workflows, notifications, ticket creation, updates to source systems, or targeted operational automations.

Step 6: Create or select a data mapping template

Data mapping templates translate source fields into Yarken fields.

Use a mapping template when external data must be loaded into Yarken consistently across repeated runs.

A mapping template should define:

Source fields
Target Yarken fields
Required fields
Default values where needed
Transformations where supported
Data type expectations
Field validation rules where applicable

Mapping templates help keep downstream reporting, allocation, planning, and analysis stable.

Step 7: Test the integration

Before enabling an integration for regular use, test it.

Check that:

Authentication succeeds
Yarken can reach the source system
The correct data is retrieved
Required fields are populated
Data mapping works as expected
Records are created or updated correctly where actions are used
Errors are visible and understandable
Results appear in the expected Yarken area

Testing should happen before data is used for reporting, allocation, planning, recommendations, or financial decisions.

Step 8: Monitor execution

After the integration is enabled, monitor execution regularly.

Review:

Last run status
Run history
Failed runs
Error messages
Records processed
Files processed
Data gaps
Permission or authentication failures
Mapping errors
Downstream reporting impact

Monitoring helps teams detect issues early and avoid stale or incomplete data.

Connector types

Pre-built connectors

Use a pre-built connector when Yarken already supports the source system.

Pre-built connectors reduce setup effort because authentication, triggers, actions, schemas, and common integration behavior are already packaged.

They are usually the best first option.

Universal connectors

Use universal connectors when the system exposes an API but does not have a pre-built connector.

Universal connectors can support common API patterns such as HTTP, OpenAPI, GraphQL, and SOAP.

They are useful for internal systems, niche SaaS platforms, partner APIs, and proprietary applications.

HTTP connector

Use the HTTP connector when you know the endpoint, method, authentication, headers, parameters, and response structure.

It is useful when the system has an API but no formal connector.

OpenAPI connector

Use the OpenAPI connector when the system publishes a usable OpenAPI specification.

This can reduce manual configuration because the specification describes endpoints, parameters, and schemas.

GraphQL connector

Use the GraphQL connector when the system exposes a GraphQL API.

Define the query or mutation, map inputs and outputs, and use it in a pipeline or recipe.

SOAP connector

Use the SOAP connector when the system exposes SOAP web services.

This is useful for older enterprise applications that rely on WSDL based service definitions.

Database connectors

Use a database connector when direct database access is the best available integration path.

Database connectors are useful when:

The system has no usable API
The database is the most complete source of truth
Large, structured datasets need to be read
Analytics workloads require direct query access
The source system is proprietary or self-hosted

Database access should be governed carefully and should follow customer security policies.

File exchange

Use file exchange when an application can export files but does not expose a practical API.

Common patterns include:

Source system exports files to SFTP
Source system exports files to cloud storage
Yarken retrieves files on a schedule
Yarken applies a data mapping template
Yarken processes the files through a pipeline

File exchange is useful for older systems, restricted systems, or systems where scheduled exports are the preferred integration method.

Custom actions

Use a custom action when an existing connector is available, but one required operation is missing.

For example, the connector may support reading records but not updating a specific field, or it may support common events but not the exact endpoint needed.

A custom action lets teams extend the connector without building a full custom connector.

Custom connectors

Use a custom connector when the integration needs to become a reusable and governed asset.

Custom connectors are useful when:

The system is proprietary or developed internally
Multiple teams need the same integration
Authentication, triggers, and actions need to be packaged together
The integration should be versioned and maintained
The integration needs to be shared across teams or environments
Universal connectors are not sufficient

Custom connectors are typically used for important or recurring integrations that should not be rebuilt manually each time.

Choosing the right approach

Use this order when selecting an integration pattern.

If a pre-built connector exists, use it.
If there is no pre-built connector but the system has an API, use a universal connector.
If the API has an OpenAPI specification, use OpenAPI.
If the API uses REST-like requests, use HTTP.
If the API uses GraphQL, use GraphQL.
If the system uses SOAP, use SOAP.
If the database is the best source, use a database connector.
If an existing connector only lacks one operation, use a custom action.
If the integration must be reusable, governed, and shared, build a custom connector.
If no API or database access exists, use file exchange.

Governance and security

Integrations should be governed like any other enterprise data flow.

Before publishing or enabling an integration, confirm:

The connection uses approved credentials or service accounts
Permissions follow least access principles
Source system access is approved
Sensitive data is handled appropriately
Owners are assigned for the integration
Run history and errors can be reviewed
Any writeback action is tested and approved
Data mappings are documented
Downstream reports and workflows are understood

This is especially important for integrations that affect financial reporting, planning, chargeback, recommendations, or automated actions in external systems.

Common use cases

Cloud and FinOps data

Use integrations to bring in cloud billing, usage, tagging, commitment, and optimization data from cloud platforms and cloud storage.

This supports FinOps analysis, cloud spend reporting, anomaly detection, and optimization workflows.

License and SaaS data

Use integrations to bring in license usage, product usage, identity, and activity data.

This supports Software License Intelligence, SaaS optimization, renewal planning, and usage-based reviews.

Finance and ERP data

Use integrations to bring in GL, budget, vendor, invoice, contract, and finance data.

This supports TBM allocation, planning, analytics, chargeback, business cases, and financial reporting.

ITSM and workflow data

Use integrations to connect tickets, incidents, requests, change events, or operational workflows.

This supports follow up actions, escalation, exception management, and collaboration between finance and technology teams.

HR and workforce data

Use integrations to bring in workforce, headcount, role, and people data where configured.

This supports workforce planning, labor cost analysis, and planning workflows.

Collaboration and notifications

Use integrations to send updates, anomalies, workflow events, or reminders to collaboration tools where configured.

This helps teams act on Yarken signals without manually monitoring every screen.

Data validation checklist

Before relying on connected data, validate that:

The source data is complete
Required fields are populated
Data types are correct
Dates and currencies are handled correctly
Entity, account, vendor, cost center, and asset mappings are valid
Duplicate records are not being created
File or API runs are not missing periods
Pipeline outputs match expected totals
Downstream dashboards and analytics reflect the loaded data correctly
Exceptions are reviewed and resolved

Troubleshooting checklist

If an integration fails, check:

Connection credentials
Source system permissions
Token expiry or authentication errors
API rate limits
File location or file naming changes
Required field changes
Data mapping template changes
Schema changes in the source system
Missing historical data
Pipeline or recipe run history
Error logs and failed records
Downstream refresh or processing status

When to use this guide

Use this guide when creating, changing, testing, or troubleshooting integrations.

Use it when deciding whether to use a pre-built connector, universal connector, database connector, file exchange, custom action, or custom connector.

Use it when configuring pipelines, recipes, data mapping templates, triggers, actions, credentials, or source system permissions.

For an overview of why integrations matter and how connected data supports Yarken’s technology finance model, refer to Connected Data Sources (Integrations).

For detailed steps on specific connector setup, pipeline creation, recipe configuration, data mapping templates, monitoring, and troubleshooting, refer to the relevant user guides.