Skip to content
Close
SEARCH
Get a demo
Get a demo

Validated, authorized, and auditable write-back to SAP Business Data Cloud (Datasphere)

Business teams maintain mappings, reference data and corrections directly in SAP Business Data Cloud (BDC) on Datasphere, while your SAP BDC team keeps the spaces, the schemas, the roles and the connections.
Get a demo
Get the deck
For the SAP BDC platform owner

Your SAP BDC is where the business reads. It is rarely where the business writes.

Reporting moved into SAP Business Data Cloud. Maintenance mostly stayed behind: cost center mappings, product groupings, ESG collections and the reference tables behind them still live in spreadsheets and reach the platform through a file and a request to your team. The platform pays back when people work inside it.

Keep business-maintained data inside SAP BDC

Every dataset maintained outside the platform is a second version of the truth, a manual load in someone's calendar, and a reason a business team keeps its own copy. Bringing maintenance inside turns a reporting platform into the system of record people use.

Auditors ask where the number came from

ESG, the EU Taxonomy and financial controls all trace back to reference data someone maintains by hand. In a spreadsheet, the answer is a folder and a memory. In the platform, the value was validated at entry and it is on the record, with the person who entered it.

AI needs the data only your business teams know

Models and agents run on the mappings, classifications and parameters that live in people's heads today. Maintained in the platform, that context arrives validated against your master data, authorized by your access model, and confirmed by a person before it is written. How NextTables powers AI.

How a business change reaches SAP Datasphere

Your business data stays in SAP Datasphere for the whole circuit, and the next change starts the same way.

  1. A business user edits

    They work in a grid they already know, on their own or inside an SAP Analytics Cloud story, signed in with your identity provider.

  2. The entry is checked first

    Values are validated against your master data and your rules while the person is still in the field, so what reaches the platform is already correct.

  3. It is written into Datasphere

    It goes into the Open SQL schema of the space your administrator created, through one database user, under the roles you defined.

  4. Reporting has it immediately

    A view in the space exposes it to your models, and SAP Analytics Cloud shows the new value at once, straight from the space.

Embedded in your SAP Analytics Cloud stories

A NextTables application embeds in SAP Analytics Cloud as a web object, in a dedicated embedded mode that shows the grid alone. URL parameters carry the story's context, so a user looking at one cost center's report edits that cost center's rows, and only those. The same application embeds in Power BI, Tableau or any tool that supports web objects.

The embedded mode is available today. A native SAP Analytics Cloud widget is on the way. Coming Soon

Schematic of a BI dashboard with key figures and a chart, and a NextTables app embedded as one tile where a product group is being maintained

What the grid, the value help and the forms look like for the people who use them: Built for business teams.

What platform owners keep and business teams gain

A maintenance layer only survives if it works for the team that runs the platform and the team that owns the data. Speed and control come from one mechanism here: the boundary is enforced by software rather than by a queue.

Platform owners keep

  • The boundary: the space, the Open SQL schema and the database user are yours. You decide which connection is available in which folder.
  • One storage location: business data lives in SAP Datasphere and only there. NextTables holds configuration metadata: applications, rules, roles, connection parameters.
  • The access model: rights are granted per folder and per table, down to the row, so a person maintains one table without holding rights on the whole space. Row-level rules can read the control tables you already maintain in the platform.
  • A clean exit: switch the connection off and the schema, the tables, the views and the data are exactly as they were.

Business teams gain

  • Their own pace: a correction takes a minute instead of a request, a file and a load window.
  • The right value, first time: search against your master data by text, so a person finds the cost center by its name rather than its number. The master data can live in this platform or in another one NextTables is connected to.
  • Their data where the report is: the same grid runs standalone or inside an SAP Analytics Cloud story, filtered by the dashboard they came from.
  • Confidence: invalid values stop at the field, so the person entering the data finds the problem instead of the person consuming it.
For owners and architects

How NextTables connects to your SAP BDC tenant

NextTables stands outside your SAP Business Data Cloud tenant and reaches it two ways, chosen per purpose: writes go through an Open SQL schema, lookups read from a space schema. SAP Analytics Cloud keeps reading the space exactly as it does today.
Architecture: SAP Analytics Cloud reads the Datasphere space schemas; NextTables, outside the tenant, writes through one Open SQL schema per space and reads master data and control tables read only

The questions an architecture board asks

Where does our business data live? Your business data stays in Datasphere, and only there. NextTables keeps configuration metadata such as applications, validation rules, roles and connection parameters, and holds the data only while it is on its way into the platform.
How does a write reach the platform? Through an Open SQL schema, created once per space by your administrator. The database user is scoped to that schema alone, so the write surface is exactly as large as the job.
What is read, and how? Master data for value help and the control tables behind row-level rules are read from a space schema through access that stays read only.Master data can also come from another connected platform: one application validates against SAP Business Data Cloud and writes to Databricks, or the other way round.
What changes for reporting? Reporting stays as it is. SAP Analytics Cloud reads the space the way it does today, one direction. A maintained value is available in reporting at once, straight from the space.
Our data access controls protect views in the space. What protects the tables in the Open SQL schema? NextTables' own authorization layer protects them. Data access controls apply to the space's views. Tables inside the Open SQL schema are reached through the connection, so the roles, the folder scoping and the row-level security objects apply to them. They can read the same control tables your data access controls already use, so one source of truth serves both. The four layers in detail: Governed.
Does a business user need edit rights on the space? A person maintains exactly the tables their role covers. Editing a table in the Datasphere Data Editor means membership of the space, with the space's rights, all of them. NextTables authorizes per folder and per table, with row-level rules on top, so a marketing user maintains one mapping table in the space while the space itself stays with the people who model it.
What does our platform's log show for a change? The connection user, because that is what a database connection is. The person behind each change is recorded in NextTables' audit log against their signed-in identity, stored in your platform. A full audit trail inside the product is on the roadmap.

Which of these landscapes is yours?

NextTables fits the ownership model you already run, and the reason you need it is different in each. Which of your spaces get an Open SQL schema is the whole design decision, and these three are the shapes it usually takes.

Central IT owns the models

One space, one Open SQL schema, one folder per business group: the central team keeps the space and the models. NextTables adds one Open SQL schema on that space and a scoped folder per group, so each group maintains its own tables through its own role.

Data product teams own their domain

One space, one schema and one folder per team: the team that owns a business area gets its own Open SQL schema on its space and its own folder. They create the table, map it in their space and join it to their models.

Access control maintained like any other table

One security space, one schema per domain: the permission tables behind your data access controls live in a dedicated security space, which is SAP's own recommendation. NextTables adds an Open SQL schema there, so each domain maintains its own entitlements, validated at entry and on the record.

The setup behind each shape, click by click: creating the database connection and scoping a connection to folders in our knowledge base.

For the SAP BDC team that will run it

What your SAP BDC administrator does, once per space

The whole setup stays inside tools your team already administers. The shape of the ask is here; the click-by-click walkthrough lives in the knowledge base.

  1. Allow one IP

    Add one trusted IP entry on the Datasphere tenant. It is set once per tenant and reused by every later connection.

  2. Create the database user

    Create it in space management, with read and write on the Open SQL schema. HDI consumption stays off.

  3. Hand over five values

    Host, port, schema, user and password go into the connection, mapped to the folders that may use it.

  4. Expose the result

    A view in the Data Builder brings the maintained table back into the space for your models and for SAP Analytics Cloud.

Step by step, including how to rotate the password and what to do when a connection stops validating: the SAP Datasphere connection guide in our knowledge base. Who may then maintain what is decided by folders, connection scoping, roles and row-level rules: Governed.

What you run, and what we run

The Datasphere-specific questions an architecture board asks once the architecture is agreed, including the parts that are still on their way. Identity, support, security and residency are the same on every platform: Governed.
ConcernYour sideOur side
ConnectivityOne trusted IP entry per Datasphere tenant, and a database user per space. Both are changes your team already knows how to make.We show the IP address in the connection dialog. Rotating the database password means replacing one value in one field.
EnvironmentsTop-level folders for development, test and production, with each environment's connection scoped to its own folder. Business users typically hold roles on production only.Available today, and the recommended structure from the first day rather than a later migration.
PromotionYou decide what is ready to move and who may move it.Export a folder or a table with everything it depends on and import it into another folder or another tenant, folder to folder in one tenant or development to QA to production across tenants. Coming Soon
Structural changeWhoever may change a table should also own the view that exposes it, because a view in the Data Builder is a live pointer and a structural change flows through to it.This is why the key user role exists as a separate, smaller grant. Align it with the people who hold modeling rights in the space and the two stay in step.
Concurrent editsToday, when two people edit the same row, the last write wins. Plan for that before rollout.Concurrency checks that warn a second editor before they overwrite are on the way. Scoped folders and row-level rules keep most teams in their own rows in the first place. Coming Soon
When you stop using NextTablesYour tables, views, schema and data are in Datasphere throughout, so they stay.Your configuration travels with the same export used for promotion, so the application definitions leave with you too. Coming Soon

Where NextTables fits, and where something else fits better

A maintenance layer is easy to oversell. These are its edges, so you can place it against what you already run in SAP Business Data Cloud.

A good fit for

  • Reference and mapping tables that business teams own and change often.
  • Corrections to data already in the platform, made by the people accountable for it.
  • Collections gathered from many contributors, for example ESG figures from subsidiaries.
  • Row-level entitlements maintained by the domains they apply to.
  • Business rule tables that transformations and models read.
  • The context data that AI and analytics depend on, still waiting for an owner end to end.

Better served by something else

  • Replacing an active master data management program. Where one already covers a domain, this sits outside it.
  • Moving or transforming data at volume. Your replication flows and pipelines keep that job.
  • Analysis and visualization. Reporting stays in SAP Analytics Cloud or your BI tool of choice, reading what is maintained here.
  • High-frequency transactional writes from an operational application.

Frequently asked questions

1. How long does it take to get a first application live?

Hours to days once the connection exists. Setup is configuration rather than development, which is also why a trial against a sandbox space is a realistic way to evaluate it.
2. Do our business users need a Datasphere account?

They sign in to NextTables through your identity provider. The platform connection runs on one database user on the Open SQL schema, so maintenance-only users stay outside your platform user lifecycle and your platform licensing.
3. Which platforms are supported today?

SAP Business Data Cloud (Datasphere), Databricks and PostgreSQL are generally available. Snowflake and Microsoft Fabric are on the roadmap.
4. Can one application maintain data across more than one platform?

Yes. An application can validate against master data in SAP Business Data Cloud and write to Databricks, with validation, authorization and traceability applied across the boundary.
5. How is NextTables licensed?

As a subscription for NextTables Cloud, sized by users and tables. The details are on the pricing page.
6. What support and release rhythm do we get?

An enterprise support model with one named path for your team, and a monthly release cycle, 30-plus releases and counting, so changes arrive on a predictable rhythm.
7. What happens to our data if we stop using NextTables?

It stays where it has been the whole time: in Datasphere. Switch off the connection and the schema, the tables, the views and every row remain as they are.

Bring your own landscape

Half an hour against your spaces, your schemas and the access model you already run. Or take the deck to your architecture board first.

Get a demo
Get the deck