Skip to main content
OpenOps integrates with Flexera One to automate the retrieval and management of cloud resource usage recommendations.

​
Actions

OpenOps provides three actions for interacting with Flexera One: All Flexera actions are based on the Flexera One API and require configuring a Flexera One connection, where you need to specify your app region, refresh token, organization ID, and project ID. The following sections describe the three actions available in the Flexera block.

​
Get Active Recommendations

Retrieves active cost optimization recommendations from Flexera:
  • Policy Set: Dynamic dropdown of available policy sets from your Flexera account
  • Filter by Provider: Optional filter by cloud provider (AWS, Azure, Google, or Alibaba)
Below is a sample output returned by this step when it is configured to request active Azure recommendations for the “Unused Volumes” policy set:

​
Get Incident

Retrieves details of a specific incident from Flexera:
  • Incident ID: The unique identifier of the incident to retrieve

​
Custom API Call

Allows making arbitrary calls to any Flexera One API endpoint:
  • URL: Dynamic endpoint selection
  • Method: GET, POST, PATCH, PUT, DELETE, or HEAD
  • Headers: Optional (authorization auto-injected)
  • Query Parameters: Optional
  • Body: Optional JSON payload

​
Designing a workflow

A typical workflow starts by collecting active recommendations using the action, then iterating through them, determining the owner of the affected resource, and deciding whether to request an action from the owner. If the owner approves the action, the workflow can remediate the resource using the actions available for the cloud platforms OpenOps supports. Below is a description of common patterns that can be implemented in your workflows.

​
Owner mapping

recommendations often need to be routed to the appropriate resource owners for review and action. OpenOps workflows can help you map cloud resources to their owners using tag values in the array returned by the action. Subsequent workflow steps may add owners or departments to the preconfigured Tag-owner mapping table. If your instance returns specific owners, your workflow can add their contact details to the Tag-owner mapping table automatically. If it does not, you can populate the table manually once for each business unit to ensure that subsequent workflow runs know which team member should receive notifications or approval requests. For an example of implementing owner mapping as a separate workflow, see Creating a workflow to fill the project-owner mapping table in the CloudHealth integration guide. While the guide covers a different FinOps product, the principles of owner mapping apply to workflows as well.

​
Recommendation tracking using OpenOps tables and states

Rather than acting on each recommendation once and then losing track of its status, your OpenOps workflow can log recommendations to the preconfigured Opportunities table for centralized tracking and status management. Workflows using the action can create or update table records with details such as estimated savings, resource IDs, recommendation types, and current status (Created, Under Review, Dismissed, Snoozed). This approach prevents duplicate notifications, provides audit trails, and enables reporting on realized vs. unrealized savings across your organization. Learn how to implement opportunity tracking by following the CloudHealth recommendation logging workflow.

​
Handling recommendations via Slack

For recommendations that require human judgment, OpenOps can send interactive Slack messages that allow resource owners to approve, dismiss, or snooze optimization opportunities directly from Slack. After retrieving recommendations with , workflows can use owner mapping to identify the appropriate Slack user, then send a Slack message with buttons for different responses using Request Action in the Slack action block. Based on the user’s decision, the workflow can mark the recommendation as rejected, delay the recommendation using the action, or proceed with remediation using OpenOps actions for the cloud provider involved. Decisions can be tracked in the Opportunities table. See Send a Slack notification with action buttons in the CloudHealth guide for implementation details.