Remotes Perfion Live Data Guide
Show stock, prices and other data that belongs to another system right next to the product record, read live from the source every time it is used, read only in Perfion, and never copied.
Perfion remote features are features whose values are read in real time from another source: a SQL database, including Perfion’s own, an OData service, or a web service built for Perfion. Each one uses a remote query over a remote connection, and a key feature matches the incoming KEYVALUE to items in Perfion. The values appear in the grid, the Item Editor and reports, live and read only, so data that belongs to another system is shown, not copied.
At a glance
- Perfion name
- Remote connections, remote queries and remote features
- Where
- Set up by Perfion administrators; remote features appear in the grid, the Item Editor and reportsRemote connectionsRemote queriesRemote featuresRemote values are read only, and shaded so editors can tell
- Used by
- Administrators and IT build the connections and queries; everyone who works with products sees the valuesNothing to maintain for editors: the source keeps the values
- Works with
- Item EditorReportsActions
- Kinds of source
- 3 kinds of source a remote reads live, including Perfion’s own databaseSSQL databaseOOData serviceWWeb service
How Perfion Remotes work, from a key in Perfion to live data on screen
A remote connects to a source, queries it for the items in use, matches each row to its item by a shared key, and shows the values in Perfion, live and read only.
Connect
A remote connection names the source: a SQL database, which can be Perfion’s own, an OData service, or a web service built for Perfion.
Query
A remote query fetches the data and shapes it into one table: a KEYVALUE column with a unique identifier, plus any data columns. It is set as Single or Cluster.
Match
The key feature holds the same identifier in Perfion, such as the item number. Each incoming row is matched to its item; rows with no matching item are ignored.
Show
Each remote feature shows one data field from the query, in the grid, the Item Editor and reports: live, read only and marked so editors can tell.
Fetch only what is needed
With the query set up for it, Perfion asks the source only for the items on screen, and one request serves every remote feature that uses the same query.
Copied data vs Perfion Remotes: what changes when data is shown, not copied
Copied data is a second version that starts to age the moment it lands. Perfion Remotes read each value from the system that owns it, every time it is shown.
| Data | Copied data | Perfion Remotes |
|---|---|---|
| Stock and open orders | Copied in every night, out of date by noon. | Read live from the source whenever they are shown. |
| Who can change a value | Anyone, in two places. | Only the source; the remote feature is read only. |
| Prices in several currencies | One feature per currency, kept by hand. | One Cluster remote with a row per currency. |
| Data spread over several tables | Exported and merged in a spreadsheet. | Joined in the remote query before it reaches Perfion. |
| How much data moves | The whole table, every time. | Only the items on screen, when the query is built for it. |
| Text in several languages | Pasted language by language. | Read by a localizable remote feature, a column per language. |
| Values worked out from Perfion itself | Counted by hand, such as a hierarchy level. | Calculated by a self-remote on Perfion’s own database. |
| A slow source | Screens wait as long as it takes. | A timeout for each query: 30 seconds unless set otherwise. |
See which of your own copied data could be shown live instead.
See it for your business →Perfion Remotes capabilities: eight ways live data reaches the product record
Each capability shows what it does in Perfion, and what it is worth to the business.
Operational Reality (Capabilities)
A remote fetches data in real time from one of three kinds of source. A SQL database is reached through a standard connection string, with ODBC or OLE DB, and it can be another system’s database or Perfion’s own, for a self-remote. An OData service is read through OData v4, for reading only and with basic data types. A remote web service can sit in front of anything else, such as another system’s own web services, a database, files or FTP, as long as it answers in the format Perfion expects.
- SQL databases, including Perfion’s own
- OData v4 services, read only
- Web services built for Perfion
Executive ROI Value
Data that belongs to another system is shown next to the product record without building an import for it.
- Live
- No copies
Operational Reality (Capabilities)
A remote feature looks like any other feature, but its values are read live from the source every time it is used and cannot be changed in Perfion. Remote values are shown on a shaded background, and remote features carry a globe in the features list. They can be added to the grid, used in the Report Designer and placed in a configuration to appear in the Item Editor. A remote feature can be localizable and inheritable; it cannot be a formula, multi-value, selectable or unique feature.
- Read live, every time
- Read only, and marked
- Grid, Item Editor and reports
Executive ROI Value
Every value has one owner. Nobody corrects the stock in Perfion and finds it overwritten, because there is nothing to overwrite.
- One owner
- One version
Operational Reality (Capabilities)
A Single remote gives one value per item, and one per language if it is localizable. A Cluster remote gives several rows per item, one per variant, such as a price for each currency. Boyum names variant structures, complex price information and calculated or combined product information as the common uses of Cluster remotes, and notes that they work very well with reports. Cluster values are shown in the Item Editor as a read-only table; they are not shown in the grid.
- One value per item
- A row per variant
- Tables in the Item Editor and reports
Executive ROI Value
Prices per currency, price list or market come from the source as one table per item, instead of a feature for each.
- Fewer features
- Richer data
Operational Reality (Capabilities)
A remote query is written so that Perfion can pass it the keys of the items in use. With three products in the grid, only three rows are fetched, not the whole table; in the Item Editor, only one. When several remote features use the same query, Perfion makes one request and reuses the data for all of them. Since Perfion 2025-R1 SR1, database queries can receive long lists of keys as a temporary table, which is typically faster. Each query has a timeout, 30 seconds unless set otherwise.
- Only the items in use
- One request, many features
- A timeout per query
Executive ROI Value
Live data stays usable at scale: the source is asked for what is needed, once, and a slow source cannot hold a screen indefinitely.
- Fast
- Predictable
Operational Reality (Capabilities)
Source data rarely has the shape Perfion needs, so it is prepared in the query. A SQL query can rename, join, calculate and build temporary tables. For OData, Perfion renames the key column, turns lists of keys into the filter the service understands, formats values by the service’s own data types, flattens nested data into columns named by their path, and can drop unwanted entries from a response before it is used. Data from a web service must already arrive in the right shape.
- SQL: rename, join, calculate
- OData: flattened and filtered
- Web services: ready-made tables
Executive ROI Value
Messy source structures are dealt with once, in the query, and every remote feature receives a clean table.
- Clean
- Done once
Operational Reality (Capabilities)
A localizable remote feature reads one column per language, named with the language code, such as Name_EN and Name_DE. A languages setting lets the query ask for exactly the languages in use: in the grid, the user’s default language; in the Item Editor, possibly all of the user’s languages. Database queries and web services can return data in this shape; Boyum notes it is practically impossible with OData, unless the service already delivers it, which is highly unlikely.
- A column per language
- Languages asked for in context
- Database and web service
Executive ROI Value
Text kept in several languages in another system appears in each language in Perfion, without being copied.
- Multilingual
- Live
Operational Reality (Capabilities)
Remote features can be used in the Report Designer like other features. Where Perfion allows it, such as in the Report Designer, a remote can run with custom values for its parameters, which then replace the values set in the query: for instance, which variants of a Cluster remote a report should show. Boyum notes that Cluster queries work very well with reports, for complex and dynamic report content.
- Used in the Report Designer
- Custom parameter values
- Cluster tables on datasheets
Executive ROI Value
Datasheets and price lists print current values from the source, for the variants each document needs.
- Current
- Tailored
Operational Reality (Capabilities)
A remote connection is named and kept on its own, and the same connection can serve many remote queries and other parts of Perfion, such as Actions, where its name is its identifier. Connections to OData services can sign in with HTTP Basic, Windows, a bearer token or OAuth through Azure Active Directory. From Perfion 5.8.2, connections for sending email through SMTP can use OAuth2 instead of a user name and password, for mailboxes where Microsoft has switched off basic sign-in.
- One named connection, many uses
- Basic, Windows, token or OAuth
- OAuth2 for email from 5.8.2
Executive ROI Value
A source is connected and secured once, and a change of server or password is made in one place.
- Secure
- Maintained once
5 Core Concepts of Perfion Remotes
The first decides what is shown rather than copied, and the second joins the two systems. The third sets the shape of the data, the fourth keeps it fast, and the last builds it once for many uses.
-
Concept 01 · One owner for every value
Show the Value Where It Lives, Don’t Copy It
The product data problem it solves
Stock and open orders are copied from the ERP into Perfion every night. By noon the numbers are wrong, sales quotes from Perfion anyway, and someone “fixes” a value in Perfion that the next copy overwrites.
The concept explained
Some product data belongs to another system: stock, open orders, prices, cost. Copying it into Perfion makes a second version that starts to age the moment it lands. A remote feature does the opposite. It reads the value from the source every time it is used, in the grid, the Item Editor or a report, and the value cannot be changed in Perfion. The source stays the only owner, and Perfion always shows what the source holds now.
Everyday analogy
The live departure board at a railway station, not a printed timetable. Nobody updates the board; it shows what the trains are doing.
BPAS method · toolDeploy EnterpriseDesign before configurationThe data model is designed and signed off before anything is configured: the Design phase of toolDeploy Enterprise.In Perfion
Remote values are shown on a shaded background and remote features carry a globe in the features list. Because the data is fetched live, it can take longer to appear than values stored in Perfion.
The source owns stock, open orders and price; a remote query asks for item PV-1002 when it is shown; Perfion displays the values read only, and nothing is copied. -
Concept 02 · The same identifier on both sides
One Key Joins the Two Systems
The product data problem it solves
Every week, stock from the ERP is matched to Perfion items with a spreadsheet lookup on the item number. Items written differently in the two systems never match, and nobody notices which ones are missing.
The concept explained
A remote works only if both systems share an identifier. The source returns its data with a KEYVALUE column holding that identifier, unique for each row, and Perfion is told which key feature holds the same identifier, typically the item number. Perfion then matches each row to its item. A row whose key is not found in Perfion is simply ignored, so the key must be unique, stable and written the same way on both sides.
Everyday analogy
A courier’s tracking number. The parcel and the website never meet, but the number connects them, as long as nobody mistypes it.
In Perfion
The key can be a feature such as the item number, or Perfion’s own item ID. For OData sources, Boyum advises against mixing data types: a key that is a number in the source and text in Perfion can cause matching problems.
Perfion’s key feature, the item number, holds PV-1001 to PV-1003; the source returns them as KEYVALUE with stock; PV-2090 has no item in Perfion and is ignored. -
Concept 03 · One value, or a table per item
Decide: One Value, or a Table per Item
The product data problem it solves
Export prices are kept in Perfion as Price INR, Price USD and Price EUR. A new market needs AED, so a new feature is added, every datasheet is changed, and the three old ones are still updated by hand.
The concept explained
Every remote is one of two types. A Single remote gives one value per item, like stock on hand. A Cluster remote gives several rows per item, told apart by a VARIANT column, like a price for each currency or each price list. Each row must be unique on its key and variant together. A new currency needs no new feature in Perfion: it is another row from the source, and at most a new variant value in the query.
Everyday analogy
A price tag on a shirt, against the menu board at a juice shop: one price, or a price for each size.
In Perfion
Single values can be shown in the grid. Cluster values are not shown in the grid; the Item Editor shows them as a read-only table with all the data columns, one row per variant.
Left, a Single remote: one stock value for PV-1002, shown in the grid. Right, a Cluster remote: three rows for PV-1002, one each for INR, USD and EUR, shown as a table in the Item Editor. -
Concept 04 · Fast because it asks for less
Ask Only for What Is on Screen
The product data problem it solves
A first attempt at live stock reads the whole stock table every time a product opens. Perfion feels slow, the source’s team complains about load, and the remote is switched off within a week.
The concept explained
Live data is only useful if it is quick. A remote query is written so that Perfion can pass it the keys of the items in use: the items in the grid, or the one item in the Item Editor. Only those rows are fetched, and when several remote features share the query, one request serves them all. While a query is set up, test mode runs it with a few test values, and Boyum recommends keeping that test data small so that editing a remote feature stays quick.
Everyday analogy
A kitchen that orders only the vegetables for today’s menu, in one delivery, instead of the whole market every time a dish is ordered.
In Perfion
Each query has a timeout, 30 seconds unless set otherwise. Since Perfion 2025-R1 SR1, database queries can receive long lists of keys as a temporary table, which is typically faster than a long list in the query.
The grid shows three items; their keys go to the remote query in one request; the source returns three rows out of 4,800, shared by two remote features. The query times out after 30 seconds by default. -
Concept 05 · Built once, used many times
One Connection, Many Queries; One Query, Many Features
The product data problem it solves
Every new ERP value shown in Perfion gets its own connection, its own query and its own password. After a server move, eleven remotes stop working, and nobody knows which ones use the old server.
The concept explained
Remotes are built in three layers that are meant to be shared. A remote connection is named once and serves many queries, and other parts of Perfion, such as Actions. A remote query can return many columns, and each remote feature shows one data field from it, so stock, open orders and a description can all come from one query. A change of server, password or query is then made once, for every feature that depends on it.
Everyday analogy
One water main, many taps. The plumber works on the main once; every tap in the house keeps flowing.
From BPAS · prodRecord newsletterprodRecordKeeping the record straight.One product data practice every month, written in plain English for product data teams.In Perfion
Each remote query can have a Setup XML for its parameters and its test and default values. It is required for web service remotes, and Boyum recommends it for all remotes because it has more features and simplifies the query.
One remote connection to the ERP database serves the stock query and an Action; the stock query returns four columns; three remote features each show one of them.
10 Best Practices for Perfion Remotes
Each practice says what a well-run set of remotes looks like and what it costs to ignore it. Designing remotes around your own systems and data is what BPAS consultants do.
-
01Show data the source owns as remotes, not as copies
The rule
Values maintained in another system, such as stock, open orders or cost, appear in Perfion as remote features, so each has one owner and one version.
Risk if ignored
Copies that age by the hour, and corrections made in Perfion that the next copy overwrites.
Get it right with BPAS
Not sure this is in place for your remotes? Talk to a BPAS consultant.
Talk to BPAS -
02Match on one unique, stable key, with the same data type on both sides
The rule
Every remote is matched on an identifier that is unique in the source and held in Perfion in the same form and data type.
Risk if ignored
Rows that silently fail to match, and remotes that break the day a key arrives as text instead of a number.
Get it right with BPAS
Not sure this is in place for your remotes? Talk to a BPAS consultant.
Talk to BPAS -
03Name every connection and query for what it returns
The rule
Remote connections and queries have names that say which source and which data they cover, as Boyum recommends, so anyone can see what depends on what.
Risk if ignored
A list of queries called Test1 and New query, and a server move that breaks remotes nobody can trace.
Get it right with BPAS
Not sure this is in place for your remotes? Talk to a BPAS consultant.
Talk to BPAS -
04Fetch only the items in use
The rule
Every remote query takes its keys from Perfion, so a grid of fifty items asks the source for fifty rows, not for the whole table.
Risk if ignored
Slow screens, unhappy owners of the source system, and remotes switched off because they were “too slow”.
Get it right with BPAS
Not sure this is in place for your remotes? Talk to a BPAS consultant.
Talk to BPAS -
05Keep test runs small, and test before use
The rule
Each query’s test values return only a few rows, as Boyum recommends, and every query is tested on known items before any remote feature uses it.
Risk if ignored
Feature definitions that take minutes to open, and wrong values shown live to the whole team.
Get it right with BPAS
Not sure this is in place for your remotes? Talk to a BPAS consultant.
Talk to BPAS -
06Shape the data in the query, before it reaches Perfion
The rule
Renaming, joining, filtering and converting happen in the query or the web service, so each remote feature receives a clean table with the right type and one row per key, or per key and variant.
Risk if ignored
Duplicate keys, wrong values on the wrong variant, and fixes attempted where they cannot be made.
Get it right with BPAS
Not sure this is in place for your remotes? Talk to a BPAS consultant.
Talk to BPAS -
07Keep each query’s parameters in one place
The rule
Every remote query keeps its parameters, test values and default values in its Setup XML, as Boyum recommends for all remotes.
Risk if ignored
Values spread between the query text and the Setup XML, where one silently overrides the other.
Get it right with BPAS
Not sure this is in place for your remotes? Talk to a BPAS consultant.
Talk to BPASRelated:Concept 05Vocabulary: Setup XML
-
08Give every source a timeout that suits it
The rule
Each remote query has a deliberate timeout for its source, rather than an assumption, so a slow or unreachable system cannot hold a screen or a report.
Risk if ignored
Editors staring at a frozen screen, and reports that fail when one source is down.
Get it right with BPAS
Not sure this is in place for your remotes? Talk to a BPAS consultant.
Talk to BPAS -
09Connect with the strongest sign-in each source offers
The rule
Connections use token-based or OAuth sign-in wherever the source supports it, including OAuth2 for email where basic sign-in is switched off, and a named administrator owns every credential.
Risk if ignored
Passwords in plain sight in connection details, and remotes and email that stop the day a password changes.
Get it right with BPAS
Not sure this is in place for your remotes? Talk to a BPAS consultant.
Talk to BPASRelated:Capability: Connections named onceGuide 09: Users and Security
-
10Treat queries on Perfion’s own database as upgrade-sensitive
The rule
Self-remotes are checked after every Perfion upgrade, because Boyum notes that its database structure is always subject to change, and Related Values are used where they do the job.
Risk if ignored
A self-remote that quietly returns nothing after an upgrade, on every datasheet that uses it.
Get it right with BPAS
Not sure this is in place for your remotes? Talk to a BPAS consultant.
Talk to BPASRelated:Guide 05: Related ValuesCapability: Three kinds of source
Perfion Remotes self-audit: how many are in place today?
Tick each of the ten practices above that your business already follows. Your score updates as you go.
Tick the practices that are in place.
Nothing you tick is stored or sent.
Illustrative scenario: an Indian pumps manufacturer, with ERP data copied into Perfion
A manufacturer of industrial and agricultural pumps carries about 2,400 items and exports to the Middle East and Africa. Product data is kept in Perfion; stock, open orders and price lists live in the ERP.
The Operational Challenge
Every night, a stock and price export from the ERP is loaded into Perfion. By afternoon the stock is wrong, and the sales team quotes from it anyway. Export prices are kept in three Perfion features, one each for INR, USD and EUR, and updated by hand whenever a price list changes.
Twice this year, datasheets went to distributors with last quarter’s export prices. Product data and sales argue over whose number is right, and corrections made in Perfion are overwritten by the next night’s load.
- Stock copied every night
- Three price features kept by hand
- Datasheets with old prices
- Two versions of every number
The Financial Transformation
Stock, open orders and lead time are now remote features, read live from the ERP database for the items on screen. Prices come from a Cluster remote, one row per currency, shown as a table in the Item Editor and printed on datasheets from the same query.
Nothing is copied, and every remote value is read only, so each number has one owner: the ERP. Each query was tested on a few known items before use, and a new currency is simply another row in the ERP.
- Stock read live, read only
- One price table per item
- Datasheets with current prices
- One owner for every number
| Cost line | Before (per month) | After (per month) | Difference (per year) |
|---|---|---|---|
| Loading and checking nightly stock and price copies | ₹ 60,000 | ₹ 8,000 | ₹ 6,24,000 |
| Keeping prices per currency in step by hand | ₹ 45,000 | ₹ 9,000 | ₹ 4,32,000 |
| Correcting quotes and datasheets with wrong data | ₹ 55,000 | ₹ 15,000 | ₹ 4,80,000 |
| Total | ₹ 1,60,000 | ₹ 32,000 | ₹ 15,36,000 |
See which of your own copied data could be shown live instead.
Book a Perfion Remotes review →prodRecord Live
Enterprise product data insights from BPAS
Keeping the record straight, live every month
prodRecord Live is a monthly webinar series on product information management, held on the second Wednesday of every month from January 2027. Each session takes one product data topic and works through it in plain English with time for your questions.
- Jan
- Feb
- Mar
- Apr
- May
- Jun
- Jul
- Aug
- Sep
- Oct
- Nov
- Dec
Who benefits when data is shown, not copied: one record, three answers
-
Promoter & CXOs
Can our teams trust the stock and prices they see next to the product data?
Values owned by another system are read live by remote features and cannot be changed in Perfion, so there is one version of every number.
-
Product Data Manager
Can my team see ERP data in Perfion without maintaining copies of it?
Stock, prices and other source data appear as read-only remote features, and prices per currency come as one Cluster table per item.
-
Perfion Administrator & IT
Can I connect a source once, securely, without slowing Perfion down?
A named remote connection serves many queries, each remote query asks only for the items in use, and every query has a timeout.
Perfion Remotes Vocabulary and Definitions
From the remote feature, the remote query and the remote connection to the key feature, KEYVALUE, Single and Cluster remotes, the data field, the Setup XML and the remote web service. Each term shows what it means, why it matters, and a household comparison.
-
Remote feature
Remotes · basicsShown live, read only
Operational definition
A feature whose values are read in real time from another source every time it is used. Its values are read only in Perfion.
Why it matters in Perfion
Data owned by another system appears in Perfion without a copy to keep up to date.
Everyday analogy
A window onto the next room: you see what is there, but you cannot move the furniture.
See it in action:Concept 01 under Core Concepts →
-
Remote query
Remotes · queryHow the data is fetched
Operational definition
The definition of how a remote fetches its data from the source and how Perfion uses it. Every remote needs one.
Why it matters in Perfion
The source is asked for the right data, in the right shape, for the items in use.
Everyday analogy
A standing order at the dairy: what to deliver, how much, and to which flat.
See it in action:Concept 04 under Core Concepts →
-
Remote connection
Remotes · sourceWhere the data lives
Operational definition
The named connection to a data source: a SQL database, an OData service or a web service. It can also be used elsewhere in Perfion, such as in Actions.
Why it matters in Perfion
A source is connected and secured once, for every query that uses it.
Everyday analogy
The water main to the building: laid once, used by every tap.
See it in action:Concept 05 under Core Concepts →
-
Key feature
Remotes · matchingPerfion’s side of the key
Operational definition
The Perfion feature that holds the same identifier as the source, such as the item number, so incoming data can be matched to items.
Why it matters in Perfion
Each row from the source lands on the right item.
Everyday analogy
The flat number on your door that the delivery slip also carries.
See it in action:Concept 02 under Core Concepts →
-
KEYVALUE
Remotes · matchingThe source’s side of the key
Operational definition
The column in remote data that holds the unique identifier, matched to the key feature in Perfion.
Why it matters in Perfion
Rows from the source can be matched without a lookup sheet.
Everyday analogy
The tracking number printed on the parcel.
See it in action:Concept 02 under Core Concepts →
-
Single
Remotes · typeOne value per item
Operational definition
A remote type that gives one value per item, or one per language if the remote feature is localizable.
Why it matters in Perfion
Simple live values, such as stock on hand, shown in the grid and the Item Editor.
Everyday analogy
One price tag on one shirt.
See it in action:Concept 03 under Core Concepts →
-
Cluster
Remotes · typeA table per item
Operational definition
A remote type that gives several values per item, one row per variant, such as a price for each currency.
Why it matters in Perfion
Prices, variants and other repeating data come as one table instead of a feature for each.
Everyday analogy
The menu board at a juice shop: one juice, a price for each size.
See it in action:Concept 03 under Core Concepts →
-
Data field
Remotes · featuresThe column a feature shows
Operational definition
The one column of remote data that a remote feature shows as its value.
Why it matters in Perfion
One query can feed several remote features, one column each.
Everyday analogy
Choosing which column of a train timetable to read: departure, platform or delay.
See it in action:Concept 05 under Core Concepts →
-
Setup XML
Remotes · configurationThe query’s settings
Operational definition
A document in a remote query, required for web service remotes, that holds its parameters, its test and default values, its type and its timeout.
Why it matters in Perfion
Every setting of a query sits in one place, where it can be read and checked.
Everyday analogy
The settings card taped inside a machine’s door.
See it in action:Concept 05 under Core Concepts →
-
Remote web service
Remotes · sourceA source built for Perfion
Operational definition
A web service built to Perfion’s remote interface: it receives Perfion’s request and returns the data as a ready-made table.
Why it matters in Perfion
Any system, file or service can feed Perfion live, through one agreed format.
Everyday analogy
An interpreter who listens to Perfion, asks the other system, and answers in Perfion’s language.
See it in action:Three kinds of source under Capabilities →
Perfion Remotes: questions product data teams ask
Short answers, each with a link to the part of this guide that explains it.
-
Remote is Perfion’s name for features that retrieve data from another source in real time. A remote feature shows its values in the grid, the Item Editor and reports like any other feature, but reads them live from the source every time it is used, and they cannot be changed in Perfion.
More on Concept 01 -
Three kinds: a SQL database reached through ODBC or OLE DB, including Perfion’s own; an OData v4 service, for reading only; and a web service built to Perfion’s remote interface, which can itself get its data from anywhere, such as another system’s web services, a database, files or FTP.
More on three kinds of source -
No. Remote feature values are read only in Perfion. They are changed in the source, and Perfion shows the new value the next time the remote feature is used.
More on remote features -
Remote data is fetched live, so it can take longer to appear than data stored in Perfion. A well-built query asks only for the items in use, and several remote features using the same query share one request. Each query has a timeout, 30 seconds unless set otherwise.
More on Concept 04 -
Yes. A Cluster remote returns several rows per item, one per variant such as a currency. The Item Editor shows them as a read-only table, and they work very well in reports. Cluster values are not shown in the grid.
More on Concept 03 -
Yes, with a localizable remote feature. The source returns one column per language, named with the language code, such as Name_EN. Database queries and web services can return data in this shape; Boyum notes it is practically impossible with OData, unless the service already delivers it.
More on every language -
Remotes work the same way whichever ERP you run, because they read from SQL databases, OData v4 services and web services built to Perfion’s interface, not from one particular ERP. Which of these your ERP offers decides how a remote reaches it; some need a web service built in between. The standard integration between Perfion and your ERP is covered in its own guide.
More on ERP integration
Still have a question?
Ask about your own products, categories and channels. A BPAS consultant will answer in plain English.
Ask BPASSee your source data live in Perfion
See how stock, prices and other data from your own systems would appear in Perfion as remotes: live, read only, and never copied. Choose the path that fits the ERP you run.
The world's first Boyum Partner Center of Excellence.Hosted in the cloud and available for evaluation and proof-of-concept work across the Boyum Solutions portfolio.See it to believe it — get convinced by working on it.Explore the PACE sandbox→