Partner enablement · Technical track

Building on Futurity

Connect a client's systems to Futurity, and run them in production.

Futurity dashboard with Corint building it from a chat request
Marketplace · Connected

ESB CoreCONNECTED

StampsCONNECTED

SalesforceConnect

See it built, then connect one yourself

Futurity
01 · 12 minHow Futurity connects
02 · 18 minCase study: Roemah Koffie
03 · 20 minHands-on: Salesforce
04 · 10 minProduction
015304560 min

CHAPTER 01

How Futurity connects

How does a question reach a client's system?

  1. Who does what4
  2. How a question flows5
  3. Three ways in6
Atlas console: systems, data sets and a query

You build and run it. Futurity reviews and backs you.

Futurity
ScopeBuildAcceptOperate You

Classify the client's system

Build or configure the plugin

Submit for review

Answer the client, fix the connector

check

platform

reviewfixes

escalate

Futurity

Confirms the way in

Runs the platform, QAor builds it, if escalated

Accepts

Fixes platform issues

Every read passes Atlas before it reaches the system

Futurity
Mockup · figures illustrative
  1. Someone asks
  2. Atlas checks
  3. Person allows
  4. Your plugin runs
  5. Answer

Corint reads your tool descriptions and picks the tools.

Three ways in. You'll see two of them today.

Futurity
Is it in the Marketplace catalog?search it first
yes

Configure

Sign in, set up. No code.

Hands-on: Salesforce
no
Does it have an API or MCP surface?documented, and we may use it
yes

Build it yourselves

You build, Futurity accepts.

Case study: Roemah Koffie
no, or first of its kind
Legacy, high-security or new to Futurity

Escalate

Futurity builds it.

CHAPTER 02 · WAY IN 2: BUILD

Case study: Roemah Koffie

What does building a plugin take?

  1. Three systems8
  2. Their traps9
  3. How fast10
  4. Live demo11
A Futurity dashboard with Corint beside it

Three systems, one question none could answer

Futurity
Which 1loyalty members 2drive sales at 3each outlet?
Stamps
loyalty CRM1

Members, tiers

invoice_number

invoice_number
= sales_numMISSING: live-data check
ESB Core
ERP and POS2

Sales per bill

sales_num

outlet + day
Excel
sales reports3

Sales per outlet

outlet, day

Illustrative question · field names from the ESB and Stamps plugins

Each system had a trap

Futurity
ESB Corelive · 15 tools

asked for

got back

Unknown filters ignored

wrong totals, no error

We drop unknown filters and say so. 30 s cap per call.

Stampslive · 12 tools
total: refused

One member per request

no totals across members

We refuse totals and wait 1 s between requests.

Excel reportscopied into Atlas
DateOutletAmountTxn IDTime12 OctKemang48.000

No transaction ID or time

joins are inferred

We copy it into Atlas and keep the join unconfirmed.

Working on day one, then four weeks of refining

Futurity
Build4 days · 37 commits

Both plugins answer questions

Tools reshaped around real questions

Refine3 weeks · 12 commits

Atlas governance added

Fixes from live use

Last change so far

ESB and Stamps plugins, built with AI coding agents · git history

Four stops, from connection to answer

Futurity
Mockup · figures illustrative

Marketplace → Connected: ESB Core and Stamps, on for the whole org.

Demo org, masked data

CHAPTER 03 · WAY IN 1: CONFIGURE

Hands-on: connect Salesforce

Can you connect one yourself?

  1. Five steps13
  2. What Corint can see14
  3. Eight questions15
Marketplace · Browse

Salesforce
Your leads, contacts, accounts and dealsConnect

Five steps to a Salesforce answer in 20 minutes

Futurity
  1. 1Get a free Salesforce org5 min
  2. 2Install the Futurity package3 min
  3. 3Connect in the Marketplace3 min
  4. 4Sign in to Salesforce2 min
  5. 5Ask, then try a write7 min

Done when Corint answers from your org, and asks before it writes · figures illustrative

Corint sees only what Atlas and your login both allow

Futurity
Your Salesforce org
Atlas grantleadscontactsaccountsopportunitiescasesorderstaskseventscampaignsother objects
Your own loginSalesforce sharing and field security still apply
What Corint answers from
8 read tools3 write tools, each asks firstDeleted records stay in the Recycle Bin for 15 days

Ask every system eight questions. Here is Salesforce.

Futurity

1Is there a documented API?Yes, REST

2May we use it?An admin installs the package

3How do we sign in?Each person's own login

4A schema, or inferred?Read live per object

5Live, or a copy in Atlas?Live

6Write back?Yes, with a prompt first

7How do we test safely?A Developer Edition org

8New to Futurity?No, it's in the catalog

So Salesforce takesConfigureAsk the same eight of your client's next system.

CHAPTER 04

Running it in production

What keeps it safe once it's live?

  1. Workflows and dashboards17
  2. Review and go live18
  3. Support19
Workflow · Morning takings

Every day, 07:00Scheduled Mode

Read takings by outletesb

Send the morning summaryApproval

The same tools run workflows and dashboards

Futurity
Mockup · figures illustrative

A workflow runs your tools on a schedule.

A plugin goes live once it passes Futurity's review

Futurity
  1. 01Buildtest in a dev org
  2. 02SubmitMISSING: submit route
  3. 03AcceptFuturity reviews
  4. 04Go livein the client's org
Review · six rules every connection must passany miss → fixes back to Build

Read-only by defaultwrites are separate tools

Least privilegeask IT only for what's needed

Secrets in the secure storenever in code or chat

Access per data setAtlas checks every read

Approval when it mattersa person confirms first

Residency before copyingrules set per org

Full acceptance checklist ships with the playbook

You take the first two lines; we take the third

Futurity
First line · you

Client questions

Access requests, how-to

Second line · you

Connector errors

Configuration, workflow fixes

Third line · Futurity

Platform issues

Product bugs, first-of-kind problems

MISSING: escalation channel and named contacts

Building on Futurity

Thank you

Questions are welcome, now or after the session.