Help

What FinOptimised does

FinOptimised shows which owner, department, and capability a cloud pound belongs to.

FinOptimised attributes cloud spend. A dedicated resource is allocated from its cost line and its Owner or CostCentre tag. A shared resource, such as a transit gateway, virtual hub, or Cloud NAT, still needs a usage figure: the tag names the accountable owner, and the usage figure divides the cost.

The same rule applies on AWS, Azure, and GCP. The crawler reads tags and relationships. It leaves every tag already in the cloud as it found it.

Executive overviewTopology and remediation

Where to work

The portal maps the organisation. Each container reads one customer environment. Help covers both.

The portal is the organisation: people, departments, capabilities, container connections, and the total cost of ownership. It reaches a container only after a sponsor grants egress for that connection.

The container runs in the customer cloud. It crawls resources, accepts bills and billing-account lists, and keeps the estate for the accounts it can see. Executive overview and the topology workspace are the container reports. They open in this same app.

Several containers can be registered on one portal account. Consolidate joins those estates into one view.

Organisation mapContainersConsolidated estate

Sign in with email

Email sign-in is available on the public app. SSO is a separate option.

Enter a work email on the sign-in page. The domain selects the organisation. The public app is configured with email sign-in on and organisation SSO off.

A private browser window keeps two organisations apart. There is no sign-out control on the page.

1. Open Sign in.
2. Enter the work email for the organisation you want to see.
3. Continue. The app stores the session for that organisation.

Sign in

Organisation SSO

SSO can be offered beside email sign-in. It is not required.

LOCAL_AUTH and SSO_ENABLED are independent. With both on, the sign-in page offers Sign in and Continue with SSO. SSO runs only when the organisation has an identity provider configured for that domain.

Set LOCAL_AUTH to false only when SSO should be the only method. The public deployment leaves email sign-in on.

Map the organisation

People, departments, and capabilities are the structure spend is attributed to.

Onboarding creates the portal account and the principal user. The organisation map starts with the company, department heads, and departments. Capabilities stay hidden until a department is opened.

Double-click a department, or right-click it and choose Show capabilities. The capabilities open in a window on the same page, and the map stays in view. Double-click a capability, or right-click it and choose Show properties and costs, to see the profile, cost, value, and revenue. Close a window to return to the previous level.

Department and capability pages are where the structure is edited. Fields can be left blank when the answer is not known yet. An assisted map can propose people from the company name. You can edit every proposed row.

1. Open the organisation map.
2. Double-click a department, or right-click it and choose Show capabilities.
3. Double-click a capability, or right-click it and choose Show properties and costs.
4. Close the windows when you want the map on its own. Use Departments and Capabilities to edit.

OnboardOrganisation mapDepartmentsCapabilities

Capabilities and cost keys

A capability can name the owner key the container should match.

A capability sits under a department. The optional container cost key is matched to owner names on the container’s spend rollup when you sync.

Sync fills empty capability fields from cloud tags. Values you have already typed stay as you typed them. The evidence of a match is kept with the capability.

Until a container reports a capability, the total cost of ownership shows the prepared portal figure for that capability. After one or more containers report it, the total is the sum of the latest figure from each container.

Total cost of ownership

Register a container

Each container has its own name, address, and access token.

The container runs in the customer cloud. Register its absolute http or https address and the access token the portal should present. Registering the same name again updates that connection. A different name adds another container.

The portal and the container do not share a network. The address has to be reachable from the portal.

1. Open Container.
2. Enter a connection name, the container base URL, and the access token.
3. Register the container. Its status stays pending until a sponsor grants egress.

Container page

Sponsor grants

A sponsor approves each container before the portal can read it.

Egress is approved per connection. A grant can expire. Deny leaves that container unread. Other granted containers on the same account are unaffected.

Sync and Consolidate both refuse a container that has no current grant. The consolidated estate lists it and records that a sponsor grant is required.

1. Choose the connection in Sponsor egress control.
2. Approve egress and record why.
3. Sync that container, or consolidate every granted container.

Container page

Several containers, accounts, and clouds

One portal account can hold many containers. One container can cover many accounts and all three clouds.

Use a separate container where the customer runs a separate landing zone, for example an Azure subscription set and an AWS payer that are not reachable from one identity.

Inside one container, a crawl accepts a list of scopes. Each scope is a provider plus an account, subscription, or project. The default crawl includes one AWS account, one Azure subscription, and one GCP project. Live calls use that container’s own credentials for each cloud.

Consolidate every container

The comprehensive estate is the join of every container the account is allowed to read.

Consolidate reads the estate view from each sponsor-approved container and stores it. Billing accounts and subscriptions from different containers are added together.

When two containers report the same provider and subscription, that subscription stays one row. The row keeps the fuller resource count and the higher cost, and it names every container that reported it. A shared resource reported twice is kept once in the same way.

Syncing one container also stores its estate, so the joined view still contains the containers you synced earlier. The public container shows this joined view after the portal that contains this Help page is deployed.

1. Grant egress on every container that should be included.
2. Open Container and choose Consolidate all containers.
3. Read the container table to see which connections were included.

Consolidate on the Container page

How tagging is used

Tags already on a resource stay. FinOptimised proposes its own keys beside them.

The crawler stores the tags it reads. It does not add, change, or delete tags in AWS, Azure, or GCP.

A dedicated cost line is allocated when Owner or CostCentre is present. Those keys may already be the customer’s tags. When a finoptimised-owner or finoptimised-costcentre key is present, allocation prefers that key.

An untagged resource can inherit an owner on the container’s copy when it is attached to exactly one tagged neighbour. Disagreement between neighbours leaves the line unallocated. The inferred owner is stored on the container’s copy and is not written back to the cloud.

Remediation report

The report lists resources that are missing an owner, a cost centre, or a FinOptimised key.

Open the topology workspace to see tagging health, the resource graph, and the remediation queue. When the container has crawled resources, the queue is built from those resources. Otherwise the queue is the prepared specimen for the signed-in organisation.

Each row shows the tags already on the resource and the FinOptimised keys to add: finoptimised-owner, finoptimised-costcentre, finoptimised-environment, and finoptimised-data-sensitivity. The hyphen form is used because a GCP label cannot contain a colon.

The Create Pull Request control is on the page for the queue. Sending that pull request is not connected. Your platform team applies the proposed keys through their own pipeline.

Topology and remediation

Who applies the tags

The customer’s platform team adds the FinOptimised keys through the pipeline they already use.

FinOptimised proposes the keys. Terraform, Bicep, or Config Connector in the customer estate is where those keys are added. Existing keys, including old or wrong ones, stay in place so other tools that read them keep working.

There is no second tagging container. The taxonomy is the list of keys this remediation report proposes.

Billing accounts and subscriptions

A bill has a parent billing account and a child subscription, linked account, or project.

The container accepts a billing-account document for AWS Organizations, Azure subscriptions, or GCP billing projects, and it accepts a bill export for all three clouds. A crawl also records the account identifiers it sees.

The estate view joins those accounts with the crawled resources and the cost lines. Inside one container that view is the whole estate that container holds. Across containers, the portal consolidation is the comprehensive view.

The container does not call AWS Organizations, Azure Billing, or GCP Cloud Billing itself. Send the account list and the bill, or let the crawl record the accounts it discovers.

Billing accounts on the topology page

Shared resources and usage

A tag names the owner of a shared resource. Usage on the bill divides the cost.

Transit gateways, virtual hubs, virtual WAN, NAT gateways, and Cloud NAT are treated as shared. A line can also be marked shared with the Shared tag.

When two or more owners have usage on that shared resource, the cost is split by usage. When the bill has no per-owner usage, the shared cost stays unallocated. FinOptimised does not pull CloudWatch, Azure Monitor, or Cloud Monitoring to invent that figure.

Executive overview

The executive page is the prepared spend picture for the signed-in organisation.

The executive overview shows total, allocated, and unallocated spend, the owners, and any shared split included in that report. It is the walkthrough report for the organisation selected at sign-in.

The joined estate, with live billing accounts and subscriptions, is the estate view and the consolidated container view. The executive page still shows its prepared report.

Executive overview

Topology workspace

The workspace shows tagging health, the resource graph, remediation, and billing accounts.

Tagged, inferred, and unallocated counts describe the topology the container last held. A resource with an owner and no cost centre still counts as tagged.

When billing accounts have been ingested or observed, they are listed with each subscription’s resources, untagged count, and cost.

Open the workspace

Total cost of ownership

TCO ranks capabilities by attributed cost and benefit.

The page shows whether egress is allowed and whether a container has been synced. Allocated cost for a capability is the prepared portal figure until a container reports that capability. After that, it is the sum of the latest amount from each container that reported it.

Benefit and the value ratio use the capability’s benefit score and that cost.

Total cost of ownership

What stays outside this product

FinOptimised reads the estate and proposes keys. Your team changes the cloud.

The crawler and the portal do not create, change, or delete cloud resources or tags. They do not open pull requests, export Azure Policy or service control policies, or send budget alerts.

A shared cost is split only when the bill already carries per-owner usage. Change events can be posted to the delta API. Nothing in the product is listening to CloudTrail, Activity Log, or Cloud Audit on its own.

The public deployment keeps the portal and the demo container in memory. A restart clears ingested bills and consolidations that were not stored in Postgres. A database-backed portal needs the container estate table added in services/portal/sql/005_container_estate.sql.