Agentforce Revenue Management (ARM)
Greenfield builds on the current model, and migrations off CPQ that don't get rebuilt twice.
Salesforce Consulting & Implementation Partner · Est. 2015
We don't just implement Salesforce. We understand the business and systems it must work with.
Greenfield Agentforce Revenue Management. CPQ built around how your business sells. Integrations that connect Salesforce to the rest of your enterprise. Architect-led from discovery through delivery.
- Architect-ledThe person who scopes it delivers it
- Evidence before changeNothing gets touched until the estate is mapped
- Fixed-scope discoveryTwo to three weeks, and the output is yours either way
- Since 2015Enterprise Salesforce, not small builds
Salesforce CPQ
Enhancement, rescue and performance work on estates that already run on it.
Enterprise integration
Platform-agnostic. The contract between systems gets written down, and so does the failure path.
Quality engineering
Automation suites that gate a release instead of decorating it.
Integration platforms handled
- MuleSoft
- Workato
- Zapier
- Boomi
- Informatica
- Oracle SOA
01MetaLens360 · Flagship accelerator
You inherited most of your org. MetaLens360 reads it back to you.
Hanya's Enterprise Discovery & Intelligence Accelerator. It reads all the Salesforce manifest metadata, including Apex, LWC, dependencies, environments and change history, and turns them into claims about your estate — each one carrying the evidence behind it.
Almost nothing in a large org was built by the people now accountable for it. It arrived — through programmes that closed, teams that moved on, acquisitions, and a decade of changes each of which was reasonable on the day it was made.
So the first question is never what to build next. It's what is actually here, and the org itself is the only honest source for that answer. MetaLens360 asks it directly: nine kinds of source read out of the platform, resolved into one graph, and reported with the strength of the evidence attached.
The product
MetaLens360
Understand what you inherited & built.
- Manual discovery
- Rapid understanding
- Informed decisions
Nine sources in, one resolved graph out. Nothing on the right is asserted without a tier on it. Scroll the diagram →
Evidence grading
Every claim MetaLens360 makes says how strongly it is known.
Unknown never becomes zero. A check that found nothing and a check that could not run are different answers, and a tool that reports them identically is worse than no tool at all. MetaLens360 keeps them apart, on every claim it makes.
Four tiers, one rule
The grade travels with the claim
A finding is only useful if you know what it rests on. MetaLens360 grades every claim by how it was arrived at, and the grade is attached to the claim — not buried in a methodology page.
- ObservedMeasured directly
- DerivedComputed from what was observed
- InferredPattern, not proof
- Not establishedReported, never dropped
What it means for a decision
Choose a tier to see what you can safely do with it.
Example claims
Showing all eight
Observed
Account.Legacy_Segment__c is referenced by four Apex classes, two Flows and one validation rule.
Observed
The named credential used by OrderSyncService points at a sandbox endpoint — in Production.
Derived
QuoteLineHelper is unreachable. No trigger, Flow, LWC or class in the resolved graph calls it.
Derived
Deleting Contract.Renewal_Tier__c breaks two CRM Analytics dashboards and the recipe that feeds them.
Inferred
The classes prefixed INTG_ look like one integration package. Nothing in the metadata declares them as one.
Inferred
Opportunity_Stage_Backup__c reads as deprecated. Nothing marks it deprecated, and it is still writable.
Not established
Field usage on Lead could not be measured: the usage API returned nothing for this object. Not zero — unmeasured.
Not established
Change history older than the org's retention window cannot be read. Those edits are unknown, not absent.
Illustrative claims, written to show the grading. Every name in them is invented.
Six questions an estate can't answer about itself.
01
What breaks if this field is deleted.
02
Which Apex classes are actually called, and which only look alive.
03
Which dashboards are built on data that stopped refreshing.
04
Where two environments have quietly drifted apart.
05
Whether a change actually propagated, or merely deployed.
06
Who owns an integration, and everything it touches.
Four stages, in order, every run.
-
Stage 01
Connect
A read-only OAuth connection to the org. No write-back and no deployment path, so there is no version of this that changes what it is reading.
-
Stage 02
Retrieve
Metadata, Apex and LWC source, dependencies, integrations, data volumes, CRM Analytics assets, environments and change history — on a schedule, or on demand before a release.
-
Stage 03
Resolve
Parsing and dependency-graph resolution. Every reference is followed until it terminates in something real, or is reported as unresolved.
-
Stage 04
Analyse
Rules, environment comparisons and AI over the resolved graph. Nothing leaves this stage without the tier of evidence that produced it.
The AI layer
It explains your org, not Salesforce in general.
The model is given your discovered assets, their relationships and their lineage. Its recommendations name classes, fields and dashboards that exist in your estate — never a generic list you could have found anywhere.
You bring your own API key; eleven providers are supported. Hanya does not resell inference, and no customer data is used to train a model.
Posture
What it can and can't do.
The connection is read-only — no write-back, no deployment capability. Credentials are encrypted at rest with AES-256-GCM. Workspaces are isolated, access is role-based per workspace, and every call is auditable.
It reads your org and reports on it. That is the whole of what it does.
MetaLens360 is live on cloud. Go and look at it.
You don't need to speak to us first. Open it, read how the evidence tiers work, and connect a sandbox when you want it pointed at your own estate.
02Enterprise complexity
Large estates don't fail at the systems. They fail at the seams.
Every system in the estate is defensible on its own terms. The damage happens between them — where two systems each hold part of the truth, and the reconciliation belongs to nobody.
Ask four people where a customer's contracted price actually lives. You'll get four answers, each pulled from a different system, each partly right, and none of them wrong enough to argue with.
That's the usual condition. Not a bad system — a truth split across several of them, with no one accountable for the join.
Counting it properly
It's also why estate size gets counted wrong. Systems are the cheap part. What has to be built, tested, monitored and re-tested every time anything changes is the set of relationships between them — and that set grows with the square.
Move the control. Nothing about the graph below changes except how many systems are in it.
The estate, drawn as its relationships
Each system added has to reach every system already there.
6 systems. 15 relationships between them.
420
Highlighted — the system added last, and every relationship it created simply by existing.
One person can still hold this Every interface fits in a single head. Questions get answered from memory, and the answers are usually right.
Seam 01
Two systems, one field
Both are authoritative. Both are current. They disagree, and the disagreement only becomes visible downstream, in a number someone escalates.
Seam 02
The interface nobody owns
It was written for a programme that closed. It still runs nightly. The person who could explain what it does on a retry has moved on.
Seam 03
The map that isn't
The architecture diagram is accurate as of the last time someone was funded to draw it. Everything since then lives in people's heads, unevenly.
Change lands weekly. The diagram gets redrawn when a programme pays for it. So the picture the business decides against is always older than the system it describes — and the longer it goes unchallenged, the more confident everyone is in it. The first job isn't choosing what to replace. It's establishing what's true right now.
03See how we think
Capability slides prove nothing. Worked problems prove something.
Four questions we get asked in almost every engagement, answered the way we'd answer them on a whiteboard — including the parts that make them awkward.
Pick a question
Reading the question…
These are worked answers written by our architects, not generated live. Every one is a real problem we have been paid to solve.
Worked example
Why your quote takes ninety seconds to calculate
Sellers stop trusting a quoting tool long before it breaks. They stop trusting it when it's slow. The cause is almost never "CPQ is slow" — it's a specific, findable thing.
- Price rules that evaluate on every line. A rule with no lookup condition runs against the whole quote each pass.
- Lookup tables queried per line rather than per quote. Fifty lines, fifty round trips.
- Custom Quote Calculator Plugin logic doing work that a formula field or a well-scoped rule could do once.
- Bundle depth. Nested option configuration multiplies the number of lines the engine has to price.
The price waterfall as a time budget
Worked example
What "it's a different data model" actually means
People hear that Agentforce Revenue Management is a re-implementation and assume it's vendor framing. It isn't. The difference is structural, and it's the reason a lift-and-shift fails.
- Legacy CPQ and Billing were separate managed packages with their own objects, reconciled by automation you wrote.
- ARM puts quotes, contracts, orders and revenue schedules on one framework — so amendments resolve against the same records instead of a synced copy.
- Product Catalog Management replaces bundle-as-product-option with attribute-driven configuration. Your bundle tree doesn't map across one-for-one.
- Which means the migration is a modelling exercise, not a data load. The data load is the easy week.
Two ways to hold the same business
Worked example
Technical debt you can see, and the kind you can't
Every org has a list of things the team knows are wrong. The dangerous debt is the stuff nobody has a name for, because nobody has read the whole org in years.
- Visible: the workflow rules nobody has migrated, the trigger with a comment saying "temporary — 2019".
- Invisible: price rules that cancel each other out, so the net effect looks correct and the logic is nonsense.
- Invisible: fields written by three automations with no defined precedence — correct until two fire in the same transaction.
- Invisible: config that only works because of a data condition that happens to be true today.
Layers, and where debt hides in each
Worked example
What we actually use AI for
Not chatbots. The useful application is reading — an org contains more configuration than a team can review by hand, so teams sample. We don't have to.
- Config archaeology. Every price rule, product rule, bundle and formula turned into a spec a business owner can argue with.
- Drift detection. Continuous diffs between sandbox and production, gated through Git before a release rather than after a rollback.
- Scenario generation. The awkward cases — co-termed ramps, partial cancels, backdated amendments — generated and run old-model against new.
- Agent-ready catalogs. Designing the product model so natural-language quoting has something unambiguous to work against.
Where the machine sits in the method
04Expertise
Seven areas. Each one described by the problem, not the product.
Anyone can list Salesforce clouds. What's worth reading is which specific failure we've seen enough times to recognise it from a screenshot.
Salesforce CPQ
Complex configuration, pricing and quoting — bundles, rules, guided selling, amendments and the arithmetic that has to still be right at renewal.
What we're unusually good at
Working out which of your price rules are commercial commitments and which are scar tissue.
Revenue Cloud
Product Catalog Management, pricing procedures, contract lifecycle, billing and the order-to-asset chain on a single data model.
What we're unusually good at
Modelling a configured-to-order catalog that survives contact with real deals.
Salesforce architecture
Org design, record structure, automation boundaries, sharing and the release process that keeps them intact under pressure.
What we're unusually good at
Telling you which constraint is real and which one is a habit the team inherited.
Integration
MuleSoft and platform integration across ERP, billing, tax, entitlement and external validation services — including the asynchronous ones.
What we're unusually good at
Designing the failure path. Most integrations are specified only for success.
AI & Salesforce intelligence
Automated metadata analysis, dependency mapping, generated documentation and catalog design that Agentforce-style quoting can actually rely on.
What we're unusually good at
Knowing the difference between reading an org and understanding it.
CRM Analytics
Dataflow and recipe architecture, dataset design, security predicates and lineage you can explain to an auditor.
What we're unusually good at
Fixing the dashboard everyone stopped believing, and finding out why.
Performance & optimisation
SOQL and Apex profiling, governor limits, automation ordering, quote calculation time and the debt sitting behind all of it.
What we're unusually good at
Measuring first. The bottleneck is almost never where the team assumes it is.
Org discovery & assessment
Two to three weeks, fixed scope. Full extraction of what's actually configured, a readable rule inventory, and a scope you can take to a budget conversation.
Yours either way
The assessment output is yours whether or not you build with us.
05Technology ecosystem
An estate isn't a logo wall. It's a set of systems that have to agree with each other.
The technologies we work in, drawn in the layers they actually sit in. Select any one for what it does inside an enterprise estate — and what tends to go wrong where it meets the next layer.
dependency
verification path
Hover, or tab to a system and press Enter
Five layers
Systems that have to agree with each other.
How to read this
Solid lines are dependencies — one layer asking another for something and waiting for an answer. The dashed path is verification: browser-level suites driving the interfaces the layers above expose.
Select any system
For what it does inside an enterprise estate, and where its seams fail. Click to pin the selection; Escape clears it.
Experience → Integration → Applications → Data → Quality
Nineteen technologies. The interesting part is the lines between them.
06Solutions
Organised by the problem you actually have.
Open any one for the problem, our approach, a real example and what changes at the end.
07Insights
Working notes, not marketing posts.
Written by the architects on live engagements. If it doesn't contain something we had to learn the hard way, it doesn't go up.
Salesforce CPQ · worked answer
How to model free months in Salesforce CPQ
Five approaches to "three months free", what each does to your renewal baseline, and the one edge case that catches almost everybody.
See it worked through → PerformanceWhere quote calculation time actually goes
Reading the CPQ price waterfall as a performance budget, and profiling it properly before touching a single rule.
In progress → Revenue CloudRunning CPQ and Revenue Cloud in one org
What coexistence requires when one line of business can't migrate: catalog separation, automation boundaries, sharing.
In progress →08Why Hanya
Small, deep, and honest about the boundary.
We're not the right call for a full platform programme. We're the right call when the revenue machinery is the risk — and we work alongside whoever owns the rest.
The architect who scoped it stays
No principal-sells-then-vanishes. The person who reads your org in week one is the person defending design decisions at cutover.
We read before we recommend
Full configuration extraction comes before the workshop, not after. It changes what questions are worth asking.
Both halves of the problem
Pricing exceptions are commercial decisions wearing technical clothes. We can hold the conversation with finance and with your dev team.
We document ourselves out
The measure of a good engagement is that you don't need us on retainer afterwards. We build with your admins, not around them.
We don't implement Salesforce. We work out what your business promised its customers, and then make the system able to keep the promise.
09Engagements
Selected engagements.
Client names are withheld under NDA. Sectors, starting conditions and scope are described accurately, and we're glad to walk through any of them on a call.
Replacing a separate configurator
Configure One→Agentforce Revenue Management
A configured-to-order line quoted outside Salesforce, with the CRM holding only the opportunity. Discovery, catalog modelling and migration scope so the quote and the order stop being two different truths.
Discovery · Catalog modelling · Migration scope
CPQ architecture for a divisional business
Fragmented CPQ→Governed model
Architect-level ownership across divisions: pricing and approval design, release governance between orgs, and untangling the customisation grown around the quote line editor.
Pricing design · Release governance · Multi-org
Coexistence assessment
CPQ (LOB A)+ARM (LOB B)
One line of business live on CPQ, a second to be built on Agentforce Revenue Management, migration explicitly out of scope. Catalog separation, automation boundaries, and what breaks if the sharing model is wrong.
Assessment · Catalog separation · Sharing model
The one you're worried about
Most engagements start with a system somebody is nervous to touch. Describe it and you'll get our read on the options — whether or not you build with us.
Start a conversation →10About
Why this practice exists.
Hanya has been consulting since 2015. What started as broad Salesforce and integration work narrowed deliberately, because the revenue side is where we kept being called back.
The pattern repeated often enough to become a thesis. A company buys CPQ, configures it around the deals in front of them, and three years later nobody can explain why a quote produces the number it produces. Not because anyone did anything foolish — because a hundred reasonable local decisions add up to a system with no author.
Undoing that is a specific skill. It needs someone who can read configuration at volume, who knows the platform's actual behaviour rather than its documentation, and who is willing to ask a CFO why a discount exists. Most firms have people who can do one of those three.
So we do one thing, we stay small enough that the person you meet is the person who does the work, and we're straightforward about the boundary of what we're good at. If your problem is Service Cloud, we'll tell you and point you at someone better.
11Careers
Trained across the stack, not parked on one product.
A young organisation since 2015, with a culture that suits an entrepreneurial streak and no appetite for defending a private patch of the work. The capability sits in the people, so that is where the training goes.
Training programme
Offered across all five disciplines.
01Enterprise systems
- Salesforce
- Workday HCM
- SAP HANA
02Integration & middleware
- MuleSoft
- Workato
- Zapier
- Boomi
- IBM WebSphere DataPower
- Oracle SOA
03Data
- Hadoop
- Informatica
- Ab Initio
04Development
- Java / J2EE
05Testing & automation
- Protractor
- TypeScript
- Cucumber
- Jasmine
- Gherkin
- Cypress
- TestCafe
What we look for
- Ambition and enthusiasm. You want the wider surface, not the safe corner of it.
- An advanced degree in an IT-related field. It is the first thing we read.
- Strong communication. Most of this work is other people's assumptions, said out loud.
Work authorisation
We sponsor H-1B visas and green cards for qualified candidates. If you already hold work authorisation, you are just as welcome — say which applies in your first email.
There is no job board. Send a CV and a line on which of the five you want to go deep on.
Email your CV →
info@hanyatechnologies.com
Direct access
Talk to an architect.
Skip the sales pitch. Talk directly with an architect who understands the problem.
- You get an architect, not an SDR The person on the call is the person who would do the work.
- Thirty minutes, diagnostic Describe what's going wrong. You'll leave with our read on the options.
- Yours either way Whatever we work out is yours, whether or not you build with us.