Skip to main content

BPAS

+91 98404 81581 Contact Us Contact Us
+91 98404 81581 Contact Us
+91 98404 81581

Actions and Automation

Perfion PIM · Complete Feature Guide

Actions and Automation Perfion Data Automation Guide

Turn the routine data work around Perfion, from supplier price lists to weekly channel exports, into Actions that run the same way every time: on a schedule, when data changes, or one click away for the people who need them.

See It for Your Business What this guide covers

Perfion Actions automate the data work around the product record: importing supplier files, exporting to other systems and channels, picking up images from hot folders, changing data and sending notifications. Each Action is an Action Map of commands that select, transform and map data through named data sources. It can be run by users from the menu or on selected items, as a scheduled job, by an Item Trigger, or through the Perfion API.

Written for product data teams, Perfion administrators and IT · By , Founder and Solution Architect · Last updated BPAS · Exclusive Boyum Practice. India's No.1 Customer-referred Boyum IT Partner.

At a glance

Perfion name
Actions, the Action library and the Perfion Scheduler
Where
Built in Actions in the main menu; run from the Tools menu, the grid, the Scheduler, Item Triggers or the Perfion APIActionsExecute ActionsSchedulerIn the web client, Actions always run on the application server
Used by
Perfion administrators build them; users run the Actions made available to themBuilding, running and scheduling need separate roles
Works with
Item TriggersPerfion APIImports
Formats as standard
6 data formats Actions read and write as standard, extendable with Add-insExcelCSVXMLFixed widthSQLAPI Query
How It Works

How Perfion Actions work, from a supplier file to a job that runs on time

An Action selects data from each source, transforms it into one shape, maps it to what Perfion or the receiving system expects, delivers it, and runs again whenever it should.

  1. Select

    Each command reads one source, such as an Excel sheet, a CSV file or data in Perfion, and turns what it needs into a flat table: one uniform shape, whatever the source looked like.

  2. Transform

    Tables are reshaped where needed, for instance when columns arrive as rows, and joined into one result on a shared key such as the item number.

  3. Map

    Each value mapping renames a column to what Perfion expects and, where needed, fixes its values with a short script. Formatting and validation happen here, and only here.

  4. Deliver

    The result is imported into Perfion, written to a file in the format another system needs, or sent on: the last command in the Action Map.

  5. Run on time

    The Action is run by an administrator, by users from the menu or on selected items, as a scheduled job, by an Item Trigger, or by a call to the Perfion API.

An illustration, not a screenshot: a supplier price list selected, joined, mapped and imported by one Action.
Manual routines vs Perfion Actions

Manual routines vs Perfion Actions: what changes when routine data work is automated

Manual routines depend on someone reformatting files, rebuilding exports and remembering the steps. Perfion Actions define the steps once and run them the same way every time, on time.

Routine product data work done by hand compared with Perfion Actions, as described in Boyum IT Solutions' Perfion documentation.
Task Manual routines Perfion Actions
Supplier price lists Reformatted by hand in Excel, file by file. Selected and mapped by an Action, the same way every time.
Different column names “Qty” and “Quantity” matched by eye. Renamed once in a value mapping.
Values with units in them “8 cm” cleaned up cell by cell. Turned into numbers by a script in the mapping.
Images for new items Uploaded one at a time. Imported from hot folders.
Weekly channel exports Built again every week. Written by an Action as a scheduled job.
Work on chosen items Item list copied into a file. Run on the items selected in the grid.
When something fails Noticed days later. Stopped, continued or handled, as set for each command.
Who can run it The one person who knows the steps. Users given the Action and the role.

See which of your own routines could run as Actions.

See it for your business
Capabilities in Depth

Perfion Actions capabilities: eight ways routine data work runs itself

Each capability shows what it does in Perfion, and what it is worth to the business.

Operational Reality (Capabilities)

Perfion Actions extract, transform and load data from many sources into Perfion, and export data from Perfion in many formats to other systems and channels. Supported formats are Excel, CSV, XML, fixed-width text, SQL and the Perfion API Query, and Add-ins can extend Actions to any proprietary format. Actions also import files and images from hot folders, export files and transformed images to set locations, change data inside Perfion, send email notifications, and run scripts and applications outside Perfion.

  • Six formats as standard
  • Files and images from hot folders
  • Email notifications

Executive ROI Value

Routine data work between Perfion and the outside world runs as one defined job, not as a person’s weekly routine.

  • Every format
  • One tool

Operational Reality (Capabilities)

Suppliers name and structure their data in their own ways: one sends Quantity, another Qty; one puts the unit in the value; one spreads data over several sheets or nests it in XML. Actions handle this in a fixed order. Selection pulls what is needed from each source into a flat table of one uniform shape, using as many selections as needed. Transformation reshapes it, for instance turning rows into columns. Mapping then renames columns and fixes values, and all formatting and validation is done on the mapped output only, from a library of functions.

  • Several selections, one table
  • Rows turned into columns
  • Checks on the output only

Executive ROI Value

Messy supplier files are handled in a predictable way, and anyone can see where each value was changed.

  • Predictable
  • Traceable

Operational Reality (Capabilities)

An Action is a named container that can be run. Its Action Map is a list of commands, ready-made functions such as selecting from a CSV file, joining two tables or importing data, each reading from and writing to named data sources, so that the output of one command becomes the input of the next. Commands can be organised in groups for overview; groups change nothing when the Action runs. A command or a whole group can be set to be ignored, which is handy while an Action is being built.

  • Commands run in order
  • Named data sources between steps
  • Groups and ignore flags

Executive ROI Value

Complex data jobs are put together from proven building blocks, and each step can be read on its own.

  • Readable
  • Built to last

Operational Reality (Capabilities)

An Action can run another Action as a sub-action. Data sources stay private to each Action: one input data source is passed to the sub-action, and Boyum recommends dividing the work so that sub-actions depend on that one input. Where several Actions need the same data, a global data source can be shared by every Action involved. A sub-action can also run in a loop.

  • One input source passed
  • Global sources when needed
  • Run once or in a loop

Executive ROI Value

A step that several jobs need, such as cleaning item numbers, is built and fixed in one place.

  • Built once
  • Fixed once

Operational Reality (Capabilities)

Each command has its own error handling. By default the Action stops if the command fails; it can instead carry on, or run a separate error-handling Action and then stop or carry on. While an Action is being built, Execute Start runs it one command at a time so the data can be checked at every step, and Execute All runs it in one go. In the web client, Actions run on the application server, and the Job window shows the progress and whether the Action succeeded or failed.

  • Stop, proceed or handle
  • Step-by-step test runs
  • Progress in the Job window

Executive ROI Value

A bad file stops the job instead of loading bad data, and someone can be told when it happens.

  • Safe
  • Visible

Operational Reality (Capabilities)

Users with the role Can execute actions can run Actions from the Tools menu, but only Actions that have been given an Appearance. An Action can also be run on items: with a Context feature such as Product, users select items in the main grid and run the Action on those items only, or on all items in the grid. Such Actions receive the selected item IDs in a data source named Items.

  • Tools menu, in folders
  • On items selected in the grid
  • Only approved Actions

Executive ROI Value

Routine jobs move from the administrator to the people who need them, without giving away the building of Actions.

  • Self-service
  • Controlled

Operational Reality (Capabilities)

An Action can run without anyone starting it. The Perfion Scheduler runs it at set times; in the web client, a scheduled job runs once, minutely, hourly, daily or monthly, with a set number of restart attempts and a delay before each if it fails, and is maintained by a Superuser or a user with the Scheduling role. An Item Trigger can run an Action when items change, and other systems can start one through the Perfion API.

  • Once to monthly
  • Restart attempts on failure
  • Triggers and API calls

Executive ROI Value

Exports go out on time, imports run before the working day starts, and follow-up work starts the moment data changes.

  • On time
  • Hands-free

Operational Reality (Capabilities)

Actions are managed in a library in the web client by users with the role Can manage actions in web client. Actions can be copied, moved between Actions a group or command at a time, and exported to Excel, one at a time or all together. Exported with names as keys, Actions can be imported to create new ones or moved to another environment; exported with IDs, the file can only update existing Actions. On import, existing Actions can be kept, skipped or replaced, and a replaced Action is deleted and created again from the file, not updated.

  • Copy and move steps
  • Export to Excel by name or ID
  • Move between environments

Executive ROI Value

An Action is tested on a test system and moved to the live system as it is, instead of being rebuilt by hand.

  • Tested
  • Moved as is
Core Concepts

5 Core Concepts of Perfion Actions

The first sets the order of the work and the second chains the steps. The third tests them before they run, the fourth decides who runs them, and the last lets routine jobs run on their own.

  1. Concept 01 · Highways, not crossing lines

    Select, Transform, Then Map

    The product data problem it solves

    Forty suppliers send price lists in forty layouts. One writes “Qty”, another “Quantity”; one sends “8 cm” in the diameter column. The import sheet is rebuilt by hand for each, and the rules live in one person’s head.

    The concept explained

    Many mapping tools let any input element be tied directly to any output field. That looks simple, until real files arrive and the lines cross in every direction. Perfion Actions enforce a process instead. Selections pull what is needed from each source into one flat, uniform table. A transformation reshapes it where needed. Only then is it mapped: columns renamed, and values formatted and validated in one place, the mapped output, so it is always clear what was changed and how.

    Everyday analogy

    A city with highways and traffic lights. Cars do not cut across fields; they join the highway, and every junction has its rules.

    In Perfion

    Boyum designed Actions to make about 95% of mapping cases simple and fast to define. Very difficult or unusual structures will need other tools.

    Related:
    BPAS method · toolDeploy EnterpriseDesign before configurationThe data model is designed and signed off before anything is configured: the Design phase of toolDeploy Enterprise.
    Select, transform, then mapStep 1, select: an Excel sheet from one supplier and a CSV file from another are each read into a flat table of one uniform shape. Step 2, transform: rows turned into columns where needed, and the two tables joined on the item number. Step 3, map: Qty renamed to Quantity, Dia renamed to Diameter, and the value 8 cm turned into the number 8; values are checked here only. Bottom: highways, not crossing lines; values are formatted and validated in one place, the mapped output.Highways, not crossing lines1 · Selecteach source, its own wayExcel · sheet DEMO, B:ECSV · item fileFlat table · one shape2 · Transformreshape and joinRows turned to columnsJoined on item numberOne result table3 · Maprename, fix, checkQty → QuantityDia “8 cm” → 8Checked here onlySelect, transform, then map, always in that orderValues are formatted and validated in one place: the mapped output.
    Two sources, an Excel sheet and a CSV file, become one flat table; the mapping renames the columns and turns “8 cm” into 8 before anything reaches Perfion.
  2. Concept 02 · One step hands over to the next

    Each Step’s Output Is the Next Step’s Input

    The product data problem it solves

    A monthly import is a 22-step checklist in a shared document. Step 14 is skipped one month, nobody notices, and two thousand items are loaded without their prices.

    The concept explained

    An Action Map is a list of commands run in order. Each command reads a named data source and writes one, and the next command picks it up: select from Excel into one table, from CSV into another, join them, then import. The steps cannot be skipped or swapped by accident, and each can be read on its own. Data sources exist only while the Action runs. When common steps are needed in many places, they become a sub-action that is passed one input source.

    Everyday analogy

    A production line. Each station takes the part from the one before, does its job, and passes it on.

    In Perfion

    A data source left without a name is called FROM or TO automatically, and these are also how a sub-action receives and returns data. Global data sources, shared by every Action involved, are marked with a $ sign.

    Related:
    Each step's output is the next step's inputFive commands in order. SET names the two source files. SELECT.CSV reads the CSV file into a table called CSV results. SELECT.EXCEL reads the Excel sheet into a table called Excel results. JOIN.LEFT joins CSV results with Excel results on the item number. IMPORT loads the joined table into Product. Right: a sub-action receives one input data source, called FROM, and returns TO; global data sources start with a dollar sign. Bottom: data sources exist only while the Action runs.One step hands over to the nextAction map · supplier price listSETFile pathsSourcesSELECT.CSVItem fileCSV resultsSELECT.EXCELPrice sheetExcel resultsJOIN.LEFTOn item numberExcel resultsIMPORTInto ProductDoneSub-actioncalled by EXECUTE.ACTIONIn · one source, FROMOut · TOGlobal · $ sign, sharedEach command's output is the next one's inputData sources exist only while the Action runs.
    SET names the two files; SELECT.CSV and SELECT.EXCEL fill two tables; JOIN.LEFT joins them on the item number; IMPORT loads the result into Product.
  3. Concept 03 · Watched while built, trusted when run

    Test Step by Step, Then Run in One Go

    The product data problem it solves

    A new import is run in full on a Friday evening. A column was mapped to the wrong feature, and on Monday the team spends the day putting back 3,000 descriptions.

    The concept explained

    While an Action is being built, Execute Start runs it one command at a time, so the data can be checked after every step; an import step still asks for confirmation before anything is written. Once it works, Execute All runs the whole Action without stopping. For every command, error handling decides what happens if it fails: stop, carry on, or run an error-handling Action first. Groups or single commands can be set to be ignored while parts of an Action are tested.

    Everyday analogy

    A trial batch before the production run, with a clear instruction at each machine for what to do if it jams.

    In Perfion

    Stop is the default if a command fails. An ignored group ignores every command inside it, whatever their own setting. Actions started by administrators in the web client run on the application server, with progress in the Job window.

    Related:
    Test step by step, then run in one goLeft: Execute Start runs the Action one command at a time. SELECT.CSV, checked. SELECT.EXCEL, checked. JOIN.LEFT, checked. IMPORT asks to run the import before anything is written. Right: if a command fails, the Action can stop, which is the default; proceed; run an error-handling Action and proceed; or run an error-handling Action and stop. Bottom: once tested, Execute All runs the whole Action, and the Job window shows progress and the result.Watched while built, trusted when runExecute Start · one command at a timeSELECT.CSV · 2 rowsCheckedSELECT.EXCEL · 2 rowsCheckedJOIN.LEFT · on item numberCheckedIMPORT · into ProductRun import?If a command failsStop · the defaultProceedError action, then proceedError action, then stopThen Execute All runs it in one goThe Job window shows the progress, and whether the Action succeeded or failed.
    Execute Start runs SELECT.CSV, SELECT.EXCEL and JOIN.LEFT one at a time, each checked; IMPORT asks before it writes. A failing command stops the Action, or hands over to an error-handling Action.
  4. Concept 04 · Built by a few, used by many

    Decide Who Runs Each Action, and Where

    The product data problem it solves

    Only the Perfion administrator can run the dealer price list export. When she is on leave, sales waits a week, and someone builds the list by hand from an old file.

    The concept explained

    Building Actions and running them are separate rights. Users with the role Can execute actions can run an Action from the Tools menu once it has an Appearance, which also decides the folder it appears in. With a Context feature, users can run it on the items they select in the grid, and the Action receives those items in the Items data source. Managing Actions in the web client needs its own role.

    Everyday analogy

    The kitchen and the counter. Recipes are written in the kitchen; the counter staff can serve any dish on the menu, but cannot change the recipe.

    In Perfion

    Appearance and Context features are normal selectable features: their values are created in Feature Data, and Context feature values must match the unique names of the features. An Action must be built for item context to work on selected items.

    Related:
    Decide who runs each Action, and whereLeft: the Tools menu, Execute Actions, with a folder called Price lists from the Appearance setting, holding two Actions: dealer price list and distributor price list. Middle: the grid, with three products selected and the Action run on them; the Action receives the item IDs in a data source called Items. Right: the roles needed: Can execute actions to run them, Can manage actions in web client to build and change them, and the Scheduling role to schedule them. Bottom: users run only the Actions made available to them.Built by a few, run by manyTools menuAppearance · Price listsDealer price listDistributor price listFolder from AppearanceGrid · ProductContext feature · ProductHW-1008 · selectedHW-1012 · selectedHW-1015 · selectedHW-1021Sent to the Action as ItemsRolesseparate rightsRun · Can execute actionsBuild · Can manage actionsSchedule · Scheduling roleUsers run only the Actions made available to themAppearance puts an Action on the menu; a Context feature puts it on items.
    The Tools menu shows a Price lists folder with two Actions; in the grid, three selected items are sent to an Action in the Items data source. Only users with the role can run them.
  5. Concept 05 · Started by a clock, a change or a call

    Let Routine Jobs Run on Their Own

    The product data problem it solves

    The marketplace feed is due every morning at 7. It goes out when the person who sends it arrives, which is 7 most days, 10 on some, and not at all during Diwali week.

    The concept explained

    The same Action can be started in several ways. The Perfion Scheduler runs it at set times; a scheduled job can run once, minutely, hourly, daily or monthly, and restarts a set number of times after a delay if it fails. An Item Trigger runs an Action when items change, and other systems can start one with a call to the Perfion API. Routine work then happens when it should, not when someone remembers.

    Everyday analogy

    A standing order at the bank. Set it up once, and the payment goes on the date, whether you think of it or not.

    In Perfion

    In the web client, scheduled jobs are maintained by a Superuser or a user with the Scheduling role. The web client scheduler does not show the log, and it cannot schedule every two weeks or the second-last weekday of a month.

    Related:
    From BPAS · prodRecord newsletterprodRecordKeeping the record straight.One product data practice every month, written in plain English for product data teams.
    Let routine jobs run on their ownFour ways to start the same Action, the marketplace feed. The Perfion Scheduler, daily at 06:00, with three restart attempts ten minutes apart if it fails. An Item Trigger, when a product status changes to Approved. A call through the Perfion API, from another system. And a user, from the Tools menu. All four start the Action, which runs on the application server. Bottom: scheduled jobs run once, minutely, hourly, daily or monthly.One Action, four ways to start itSchedulerDaily · 06:003 restartsItem TriggerStatus → ApprovedOn changePerfion APICall from a systemOn requestUserTools menuBy handActionMarketplace feedApplication serverOut by 06:05, every dayStarted by a clock, a change or a callScheduled jobs run once, minutely, hourly, daily or monthly, and restart if they fail.
    One Action, four starters: the Scheduler at 06:00 daily with three restart attempts, an Item Trigger, a call through the Perfion API, and a user from the Tools menu.
Best Practices

10 Best Practices for Perfion Actions

Each practice says what a well-run set of Actions looks like and what it costs to ignore it. Designing automation around your own data and routines is what BPAS consultants do.

  1. 01Name and describe every Action and every step

    Build · Documentation

    The rule

    Each Action has a clear name and a description of what it does, and each command and mapping carries a short note on why it is there.

    Risk if ignored

    Actions nobody dares change, because nobody remembers what they do.

    Get it right with BPAS

    Not sure this is in place for your Actions? Talk to a BPAS consultant.

    Talk to BPAS

    Related:Concept 02Vocabulary: Action

  2. 02Group the steps of each Action by stage

    Build · Structure

    The rule

    Commands sit in groups that follow the stages of the work, such as select, join and import, so the Action reads from top to bottom.

    Risk if ignored

    Long, flat lists of commands that take an hour to follow and minutes to break.

    Get it right with BPAS

    Not sure this is in place for your Actions? Talk to a BPAS consultant.

    Talk to BPAS

    Related:Capability: Actions built from commandsConcept 02

  3. 03Build shared steps once, as sub-actions with one input

    Build · Reuse

    The rule

    Steps that several Actions need are kept as one sub-action that takes a single input data source, as Boyum recommends.

    Risk if ignored

    The same clean-up built five times, fixed in two places, and wrong in three.

    Get it right with BPAS

    Not sure this is in place for your Actions? Talk to a BPAS consultant.

    Talk to BPAS

    Related:Concept 02Vocabulary: Sub-action

  4. 04Change and check values only in the mapping

    Build · Data

    The rule

    Values are formatted and validated in the mapping stage, and nowhere else, so every change to the data can be found in one place.

    Risk if ignored

    Values altered at several points in the Action, and nobody able to say where a wrong one came from.

    Get it right with BPAS

    Not sure this is in place for your Actions? Talk to a BPAS consultant.

    Talk to BPAS

    Related:Concept 01Vocabulary: Value mapping

  5. 05Test new and changed Actions step by step, on test data

    Testing · Before go-live

    The rule

    Every new or changed Action is run one command at a time on test data, and its result checked by someone who knows the data, before it runs in full.

    Risk if ignored

    A wrong mapping run in full against the live product record.

    Get it right with BPAS

    Not sure this is in place for your Actions? Talk to a BPAS consultant.

    Talk to BPAS

    Related:Concept 03Guide 17: Import and Export

  6. 06Decide for every step what happens if it fails

    Testing · Errors

    The rule

    Each command that can fail has a deliberate setting: stop, carry on, or run an error-handling Action that tells someone.

    Risk if ignored

    Half-finished jobs that load part of a file, and failures that nobody hears about.

    Get it right with BPAS

    Not sure this is in place for your Actions? Talk to a BPAS consultant.

    Talk to BPAS

    Related:Concept 03Vocabulary: Error handling

  7. 07Give users only the Actions they need, where they need them

    Access · Users

    The rule

    Users run approved Actions from the menu or on selected items; building and changing Actions stays with a few trained people.

    Risk if ignored

    Actions run by the wrong people on the wrong items, or changed by someone testing an idea.

    Get it right with BPAS

    Not sure this is in place for your Actions? Talk to a BPAS consultant.

    Talk to BPAS

    Related:Concept 04Guide 09: Users and Security

  8. 08Schedule recurring jobs, and check that they ran

    Automation · Schedule

    The rule

    Recurring imports and exports run as scheduled jobs with restart attempts, and a named person checks the result of every run.

    Risk if ignored

    Jobs that depend on someone remembering, and scheduled jobs that fail quietly for weeks.

    Get it right with BPAS

    Not sure this is in place for your Actions? Talk to a BPAS consultant.

    Talk to BPAS

    Related:Concept 05Vocabulary: Scheduled job

  9. 09Move Actions between environments by export, not by rebuilding

    Library · Environments

    The rule

    Actions are built and tested on a test system and moved to the live system by exporting them with names, with a backup of any Action that will be replaced.

    Risk if ignored

    Live Actions that differ from the tested ones, and a replace that silently deletes steps added only on the live system.

    Get it right with BPAS

    Not sure this is in place for your Actions? Talk to a BPAS consultant.

    Talk to BPAS

    Related:Capability: An Action library you can moveConcept 03

  10. 10Refresh the Actions set-up after every major upgrade

    Library · Upgrades

    The rule

    After each major Perfion upgrade, the Actions set-up is installed again, as Boyum recommends, so new functions and commands are available.

    Risk if ignored

    New commands missing from your system, and Actions built around gaps that an upgrade had already closed.

    Get it right with BPAS

    Not sure this is in place for your Actions? Talk to a BPAS consultant.

    Talk to BPAS

    Related:Capability: Actions built from commandsVocabulary: Command

Self-Audit · 10 Best Practices

Perfion Actions 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.

Practices in place
0 of 10

Tick the practices that are in place.

Book a Perfion Actions review

Nothing you tick is stored or sent.

Illustrative scenario · not a client case study A Business Like Yours

Illustrative scenario: an Indian hardware distributor, with routine data work done by hand

A distributor of industrial fasteners, hand tools and fittings carries about 18,000 items from 40 suppliers, and sells to dealers across India, through a B2B webshop and on two marketplaces. Product data is kept in Perfion.

The Operational Challenge

Every week, two people reformat supplier price lists by hand: each supplier has its own layout, column names and units, and every file is rebuilt into the import sheet before it can be loaded. Images arrive in shared folders and are uploaded one item at a time. The dealer price list and the marketplace feeds are rebuilt every Monday from exports.

The steps live in one person’s head. When he is away, price changes wait, and a feed with missing columns has already been rejected twice this quarter.

  • Supplier files reformatted by hand
  • Images uploaded one by one
  • Feeds rebuilt every week
  • Steps known to one person

The Financial Transformation

Each supplier now has an Action that selects its file, maps its columns and fixes its values, joined with existing item data and imported. A shared sub-action cleans item numbers for all of them. Images are imported from hot folders, and the dealer price list and marketplace feeds go out as a scheduled job before the working day starts.

Every Action was tested step by step before going live, a failed import stops and alerts the team, and category managers run the dealer list for selected items themselves, from the grid.

  • One Action per supplier layout
  • Images picked up from folders
  • Feeds out before 7 every morning
  • Users run approved Actions
Illustrative figures for a typical Indian distributor of this size. They add up, but they are not a client case study.
Cost line Before (per month) After (per month) Difference (per year)
Reformatting supplier price lists₹ 90,000₹ 18,000₹ 8,64,000
Rebuilding dealer and marketplace feeds₹ 50,000₹ 8,000₹ 5,04,000
Uploading images and fixing failed imports₹ 40,000₹ 10,000₹ 3,60,000
Total₹ 1,80,000₹ 36,000₹ 17,28,000
Illustrative saving a year₹ 17,28,000Same figures as the table, not a client result

See which of your own routines could run as Actions.

Book a Perfion Actions review
From BPAS

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.

  1. Jan
  2. Feb
  3. Mar
  4. Apr
  5. May
  6. Jun
  7. Jul
  8. Aug
  9. Sep
  10. Oct
  11. Nov
  12. Dec
Explore prodRecord Live
12
Live sessions in 2027 Second Wednesday, monthly
Who Benefits

Who benefits when routine data work runs itself: one record, three answers

  • Promoter & CXOs

    Can supplier prices, dealer lists and marketplace feeds go out on time, even when key people are away?

    Routine jobs run as Actions, the same way every time, on a schedule or one click away, so they no longer depend on one person.

  • Product Data Manager

    Can my team stop reformatting supplier files and rebuilding the same exports every week?

    Each supplier layout is handled by an Action with its own value mapping, images come in from hot folders, and approved Actions run from the menu or on selected items.

  • Perfion Administrator

    Can I see what each job does, test it safely, and control who runs it?

    Each Action Map reads step by step, error handling is set for every command, and Appearance and roles decide who runs what.

Vocabulary

Perfion Actions Vocabulary and Definitions

From the Action, its commands and the Action Map to data sources, value mappings, sub-actions, error handling, Appearance, Context features and scheduled jobs. Each term shows what it means, why it matters, and a household comparison.

  1. Action

    Actions · basics

    A job Perfion can run

    Operational definition

    A named set of steps in Perfion that can be run: it imports, exports, transforms or changes data without someone doing the work by hand.

    Why it matters in Perfion

    Routine data work is done the same way every time, by Perfion.

    Everyday analogy

    A recipe card: the same dish, made the same way, by whoever follows it.

    See it in action:How it works →

  2. Command

    Actions · building block

    One step, ready-made

    Operational definition

    A ready-made function that does one job in an Action, such as reading an Excel sheet, joining two tables or importing data.

    Why it matters in Perfion

    Actions are built from proven steps instead of code.

    Everyday analogy

    A kitchen appliance: the mixer mixes, the oven bakes; you choose the order.

    See it in action:Actions built from commands under Capabilities →

  3. Action Map

    Actions · structure

    The steps, in order

    Operational definition

    The commands in an Action, run in order, each with the data sources it reads from and writes to.

    Why it matters in Perfion

    Anyone can read what an Action does, step by step.

    Everyday analogy

    The route card that travels with a job through the factory.

    See it in action:Concept 02 under Core Concepts →

  4. Data source

    Actions · data

    What passes between steps

    Operational definition

    A named set of data an Action works on while it runs: usually a table or an XML document held in memory, or a file path.

    Why it matters in Perfion

    Each step hands a clear, named result to the next.

    Everyday analogy

    A labelled tray passed from one workstation to the next.

    See it in action:Concept 02 under Core Concepts →

  5. Value mapping

    Actions · mapping

    Rename and fix

    Operational definition

    A line under a command that renames an input column for the output, and can change its values with a short script.

    Why it matters in Perfion

    Supplier names and formats become Perfion’s, in one visible place.

    Everyday analogy

    A translator who also converts inches to centimetres as she goes.

    See it in action:Concept 01 under Core Concepts →

  6. Sub-action

    Actions · reuse

    Built once, called often

    Operational definition

    An Action run by another Action and passed one input data source, so that common steps are built once and reused.

    Why it matters in Perfion

    Shared steps are fixed once, for every job that uses them.

    Everyday analogy

    A standard sub-assembly fitted into many different products.

    See it in action:Reusable steps under Capabilities →

  7. Error handling

    Actions · safety

    When a step fails

    Operational definition

    What an Action does if a command fails: stop, carry on, or run an error-handling Action and then stop or carry on.

    Why it matters in Perfion

    Bad files stop the job, and someone can be told.

    Everyday analogy

    The emergency stop on a machine, with a phone number beside it.

    See it in action:Concept 03 under Core Concepts →

  8. Appearance

    Actions · users

    On the menu

    Operational definition

    The setting that lets users run an Action from the Tools menu, where it sits in a folder of the same name.

    Why it matters in Perfion

    Users run approved jobs themselves, without waiting for an administrator.

    Everyday analogy

    A dish printed on the menu: anyone can order it, nobody changes the recipe.

    See it in action:Concept 04 under Core Concepts →

  9. Context feature

    Actions · items

    Run on chosen items

    Operational definition

    The setting that lets users run an Action on items of a chosen feature, such as Product, from the grid.

    Why it matters in Perfion

    Work is done on exactly the items a user picks.

    Everyday analogy

    Ticking boxes on a form so that only those orders are dispatched.

    See it in action:Run by users under Capabilities →

  10. Scheduled job

    Actions · automation

    Runs on time

    Operational definition

    A job in the Perfion Scheduler that runs at set times, once, minutely, hourly, daily or monthly, and can restart if it fails.

    Why it matters in Perfion

    Recurring imports and exports happen on time, without anyone starting them.

    Everyday analogy

    An alarm clock that also makes the tea.

    See it in action:Concept 05 under Core Concepts →

FAQ

Perfion Actions: questions product data teams ask

Short answers, each with a link to the part of this guide that explains it.

  1. Bring data into Perfion from many sources and formats, export data from Perfion in many formats to other systems and channels, import files and images from hot folders, export files and transformed images to set locations, change data inside Perfion, send email notifications, and run scripts and applications outside Perfion. Excel, CSV, XML, fixed-width text, SQL and the Perfion API Query are supported as standard.

    More on data in and out

  2. Actions are built from ready-made commands, their settings and value mappings, and Boyum designed them to make about 95% of mapping cases simple and fast to define. Short scripts are used where values need converting, and very difficult or unusual structures will need other tools. Building Actions still takes a good understanding of Perfion and of the data.

    More on Concept 01

  3. Yes. Running and managing Actions are separate roles. Users with the role Can execute actions can run the Actions that have been given an Appearance, from the Tools menu, and those with a Context feature on items they select in the grid. Managing Actions in the web client needs the role Can manage actions in web client.

    More on Concept 04

  4. In three ways besides being run by hand. The Perfion Scheduler runs them at set times; in the web client, once, minutely, hourly, daily or monthly, with restart attempts if a run fails. Item Triggers can run an Action when items change. And other systems can start an Action with a call to the Perfion API.

    More on Concept 05

  5. That is decided for each command. By default the Action stops; a command can instead let the Action carry on, or run an error-handling Action and then stop or carry on. Administrators can follow Actions running on the application server, and see whether they succeeded or failed, in the Job window.

    More on Concept 03

  6. Yes. Actions can be exported to Excel and imported into another Perfion system. Exported with names, they can create new Actions or replace existing ones; exported with IDs, they can only update existing Actions. Replacing an Action deletes it and creates it again from the file, so it is wise to export the existing one first.

    More on Import and Export

  7. Yes. Actions work on Perfion’s own data and on files and systems around it, so this guide applies whichever ERP your business runs. How Perfion connects to 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 BPAS
Works Together With

See your routines running as Actions

See how your own supplier files, exports and recurring data jobs would run as Perfion Actions, tested, scheduled and in the right hands. Choose the path that fits the ERP you run.

Running an enterprise ERP?Book a product data assessment On SAP Business One or Business Central?Explore Boyum solutions, B1UP and toolDeploy
World first · 2025The 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