Validation and Business Rules Perfion Data Governance Guide
Check every value as it is entered, stop what must never be wrong, warn about the rest, and let each change set off its next step.
Validation keeps product data right as it is entered and makes sure changes are followed up. A business rule on a Number, String or Text feature checks each value with a regular expression or a number range. Hard validation rejects an invalid value, and soft validation warns before saving, with the feature’s help text explaining the rule. An Item Trigger reacts to changes, for example by sending an approved product back to review, and a comment with a colleague tagged brings them straight to the item.
At a glance
- Perfion name
- Business Rules, Item Triggers and Comments
- Where
- Feature definitions, the grid, the Item Editor and importsBusiness rulesItem TriggersCommentsItem Triggers: Perfion 2021-R2 and later
- Used by
- Product editors and administratorsAn administrator activates Item Triggers
- Works with
- Feature typesPick listsItem Editor
- Documented rule types
- RegEx and Number rules, each hard or soft, with item base value versions for pick lists*RegEx#Number*RegEx (item base value)#Number (item base value)
How validation works in Perfion, checked in, followed up
Business rules check each value as it comes in. Item Triggers react to the changes that are made. Comments bring the right person to the item.
Set the rule on the feature
A business rule is set once, on the feature, such as an HSN code of exactly eight digits or a wattage greater than 0 and at most 50. It applies to every item that uses the feature.
Check each value as it comes in
Values are checked in the main grid, including copy-paste and mass updates, in the Item Editor, in Replace and Compare, and in imports.
Reject or warn
A hard rule rejects an invalid value. A soft rule warns and asks the user to confirm. Either way, the feature’s help text explains what is expected.
Trigger the next step
An Item Trigger reacts to a change, for example by setting Status to Review on an approved product, or by running an Action.
Bring in the right person
A comment on the item tags a colleague with @. The bell in Perfion turns red, and an email follows if they have chosen email notifications.
Checked by hand vs Perfion validation: what changes when values are checked as they are entered
Checked by hand, errors are found late, by a reviewer or a channel. In Perfion, each value is checked as it comes in, and each change sets off its next step.
| Task | Checked by hand | Perfion business rules, triggers and comments |
|---|---|---|
| Codes such as HSN and EAN | Typed with a missing digit or a space, and found when a document or a listing fails. | A regular expression checks the format, such as exactly eight digits, as the value is entered. |
| Measurements such as wattage | “9W”, “9 watts”, or 90 by mistake, with nothing to stop it. | A Number rule flags any value outside the agreed range. |
| Telling editors what is expected | A style guide in a shared folder that few people open. | The feature’s help text appears the moment a value breaks the rule. |
| Values that must never be wrong | Checked by a reviewer, if there is time. | Hard validation rejects them, so they cannot be saved. |
| Values that should follow a guideline | Ignored, or argued about in review. | Soft validation warns the user, who corrects the value or confirms it. Accepted exceptions stay marked yellow. |
| Supplier and bulk files | Imported first, then cleaned for weeks. | An import with hard invalid values is rejected, with the reasons. Soft warnings are listed in the log. |
| What happens after a change | Someone remembers to tell the reviewer, or does not. | An Item Trigger sets a status, updates another value or runs an Action, whether the change was made in the grid, the Item Editor, an import or the API. |
| Questions about a product | Asked in email threads, away from the product. | A comment on the item tags a colleague, who gets a notification with a link straight to it. |
See how your own data standards would be checked in Perfion.
See it on your product data →Perfion validation capabilities: eight ways to keep data right
Each capability shows what it does in Perfion and what it is worth to the business.
Operational Reality (Capabilities)
A business rule is an extended rule on a feature that limits the values users can set beyond what the feature type defines, such as allowing only 50 characters in a String feature. Rules can be set on Number, String and Text features, and are enforced through all user interfaces and through import. On a localizable feature, one rule applies to every language. On an inheritable feature, the rule is enforced at the level where the value is set. On a feature that allows multiple values, each value is checked, and one invalid value makes the whole set invalid. Rules cannot be set on formula, remote or rich text features.
- Number, String and Text features
- One rule for every language
- Each value of a multi-value feature checked
Executive ROI Value
Data standards stop being a document people are asked to follow and become part of the product record itself.
- Errors prevented, not cleaned up
- One standard for every editor
Operational Reality (Capabilities)
With the RegEx rule type, a value must match a regular expression. Boyum’s documentation gives examples that can be used as they are or adapted: a length between 1 and 35 characters, only letters, underscores and spaces, only digits with a length of 8 to 10, a text that must contain a given word, and a code that starts with AB or CD followed by two digits. The Perfion interface does not help write the expression, so patterns are written and tested by someone who knows them.
- Length limits on text
- Allowed characters only
- Code formats such as a fixed number of digits
Executive ROI Value
HSN codes, EANs and internal codes keep their exact format across thousands of products, so documents and listings built from them do not fail.
- Fewer rejected listings
- Codes other systems can trust
Operational Reality (Capabilities)
For Number features, the Number rule type sets a range for values to match, such as greater than 0 and at most 100. One or two operators can be used, from less than, at most, greater than, at least, equal to and not equal to, with whole numbers, negative numbers or decimals. Boyum notes that two contradictory operators, such as below 50 and above 100, make every value invalid.
- Six operators
- One or two limits per rule
- Decimals and negative numbers
Executive ROI Value
Weights, wattages and dimensions stay within what the product can actually be, so a slipped digit is caught before a customer sees it.
- A slipped digit caught on entry
- Specifications buyers can rely on
Operational Reality (Capabilities)
Every rule is enforced in one of two ways. With hard validation, an invalid value is never accepted: the user is told the rule and asked to change the value. With soft validation, the value is accepted, but the user is told the rule and asked to confirm before saving. Values that break a hard rule are marked red, and values that break a soft rule are marked yellow, in the grid and the other interfaces. The feature’s help text is optional, but Boyum calls it important: it is shown to users wherever they try to enter an invalid value.
- Hard: rejected, marked red
- Soft: warned, marked yellow
- Help text shown with every alert
Executive ROI Value
Values that must never be wrong are protected, while house style guidelines are encouraged without blocking the work.
- Strict where it matters
- Flexible where it helps
Operational Reality (Capabilities)
Rules are checked in every user interface and in imports. In the grid, an alert with the help text must be answered before moving on, and copy-paste and mass updates are checked too. In the Item Editor and in Compare, each new value is checked as it is entered, and Compare also checks values copied from one item to another. A Replace value is checked before the Replace runs. An import with hard invalid values is rejected, and the user is told why; an import with only soft invalid values goes ahead, and the log lists them. One documented exception is copying: copying items, children and relations does not enforce rules.
- Grid, copy-paste and mass updates
- Item Editor, Replace and Compare
- Imports rejected on hard errors
Executive ROI Value
Bad data cannot slip in unnoticed through a bulk update or a supplier file, so clean-up projects become rare.
- Supplier files checked on arrival
- Bulk edits held to the same standard
Operational Reality (Capabilities)
An Item Trigger defines a scenario in which a change to an item makes Perfion respond. It is set on one selectable base feature, such as Product, and reacts either to changes in one or more features or to an item being created or deleted. Optional conditions narrow it down, such as only when Status is Approved. Its activity updates a feature value, such as setting Status to Review, or runs an Action. Triggers fire on update in the grid, on save in the Item Editor and in Compare, and on changes through imports and the API. Each trigger can be enabled or disabled, and when two triggers change the same feature, the higher priority wins. Item Triggers need Perfion 2021-R2 or later and are activated by an administrator.
- Feature changes, or items created and deleted
- Optional conditions
- Set a value or run an Action
Executive ROI Value
Review steps and follow-up work happen every time, not only when someone remembers, and people keep working exactly as before.
- No missed reviews
- No monitoring jobs running all day
Operational Reality (Capabilities)
When an Item Trigger runs an Action, it passes the details of the affected items in three sets: the item before the change, after it, and both combined. When an import changes many items at once, all of them are passed in one set. Boyum’s example copies the previous EAN to a backup feature whenever the EAN changes, and its listed uses include regenerating an export file or a report. Triggered Actions need the Application Server to be running, and the trigger log shows each run with its status: New, Queued, Started, Success, Failed or AbnormalTermination. Before Item Triggers, the same result needed external modules or a scheduled Action that kept monitoring all the data.
- Before, after and combined details
- Many items handled in one run
- A status for every run
Executive ROI Value
Follow-up work such as refreshing an export or keeping the history of a value runs straight after the change, and every run can be checked.
- Exports refreshed on change
- Every run traceable
Operational Reality (Capabilities)
A comment can be added to any clickable item in Perfion, including in the Item Editor. Typing @ tags the colleagues who should see it. A tagged user gets a notification: the bell at the top of Perfion turns red, and the notifications list shows the message, the time, the author and a link straight to the item. Users who choose email notifications also get an email with the sender, the text, a direct link to the Item Editor for that product and context to act on it.
- Comments on any clickable item
- @ tags for the right colleagues
- Bell in Perfion, email if chosen
Executive ROI Value
Questions about a product stay with the product, so answers are not lost in inboxes and reviews move faster.
- Fewer email threads
- Answers kept on the item
5 Core Concepts of Checking and Governing Product Data
The first two are about preventing errors. The next two are about keeping data clean. The last is about following up on changes.
-
Concept 01 · Stop bad values on the way in
Check Values at Entry, Not After the Fact
The product data problem it solves
HSN codes and EANs are typed by hand and checked by nobody until a document is questioned or a marketplace rejects a listing. By then, the wrong code has been copied into price lists, catalogues and partner files.
The concept explained
Every wrong value costs more the further it travels. Caught as it is typed, it takes seconds to fix. Found in a channel, it means finding every copy, correcting each one and explaining the error. The cheapest check is the one at the point of entry. A business rule on the feature does exactly this: it checks each value as it comes in, whether it is typed in the grid, edited in the Item Editor, replaced in bulk or brought in by an import, and stops or flags it there.
Everyday analogy
A railway ticket gate. It checks every ticket at the entrance, not halfway through the journey.
In Perfion
Business rules are set at feature level on Number, String and Text features and are enforced through all user interfaces and through import. Invalid values are highlighted in the grid and the other interfaces: red for hard rules, yellow for soft rules.
Three routes in, one rule on the feature. The valid code goes into the record; the wrong ones are stopped at entry. -
Concept 02 · Match the response to the risk
Stop What Must Never Be Wrong, Warn About the Rest
The product data problem it solves
A team makes every guideline a strict rule. Editors are blocked by title lengths and style points, start working around the rules, and the rules that really matter lose their weight.
The concept explained
Not every rule carries the same risk. A barcode with a missing digit must never be saved. A web title a little over the house length is worth a warning, not a block. Perfion lets each rule be enforced the right way: hard validation rejects the value outright, and soft validation warns the user and lets them confirm. Either way, the feature’s help text tells the user what is expected, so the alert teaches the standard instead of only refusing the value.
Everyday analogy
Traffic signals. A red light stops you; an amber light warns you and leaves the decision to you.
In Perfion
Every rule is enforced as hard validation, which rejects illegal values, or soft validation, which allows them but warns the user before saving. In imports, hard invalid values reject the import; soft invalid values are imported and listed in the log.
Related:A hard rule rejects a 12-digit EAN. A soft rule warns about a long title, and the user confirms it. -
Concept 03 · Correct once, at the source
Fix the List, Not Every Product
The product data problem it solves
A rule is added to the finish list, and old finish names that break it are corrected product by product, hundreds of times, while the products that still use them look perfectly fine.
The concept explained
A value picked from a list is held once, on the list item, and every product that picks it shares it. So a rule on a selectable feature is checked where the value is made: on the list item itself. A new list value that breaks the rule is rejected. Old list values that break it can still be picked, and products that use them are not marked as invalid. Boyum describes this as a deliberate design decision: the correction belongs on the list item, where one fix corrects every product that uses it.
Everyday analogy
Correcting a misspelt name in a school register. Fix the register once, and every report card printed from it is right.
In Perfion
On selectable features, rules are enforced on the base value of the list items; no check is made when an item is picked as a value. In imports allowed to create new list values, the new values are checked, and an import with one that breaks the rule is rejected. Features with identity inheritance take the rule of their parent feature.
Related:A new finish that breaks the rule is rejected. An old one is corrected once, on the list, for every product. -
Concept 04 · Plan for what rules leave out
Know Where Rules Do Not Reach
The product data problem it solves
A team switches on rules and assumes the data is now clean. Months later it finds invalid values on copied products, empty fields that everyone thought were required, and old errors that were never revisited.
The concept explained
Rules are a strong guard at the point of entry, and Boyum documents clearly where they do not apply. Empty values are never checked, so a rule does not make a value required. Copying items copies their values as they are, valid or not. Saving in the Item Editor does not recheck old values, so new work can be saved on an item that still holds old errors. No check is made when a value is picked from a list. Rules cannot be set on formula, remote or rich text features. Knowing these limits turns rules from a hope into a plan.
Everyday analogy
A smoke alarm. It protects the room it is fitted in, every time, but not the room next door.
From BPAS · prodRecord newsletterprodRecordKeeping the record straight.One product data practice every month, written in plain English for product data teams.In Perfion
Empty cells are never validated and are valid by default. The copy function for items, children and relations does not enforce rules. No validation is done when the Item Editor is saved. No check is made when a selectable item is picked as a value.
What business rules check, and where they stop, as documented by Boyum. -
Concept 05 · Changes that set off what comes next
Let a Change Trigger the Next Step
The product data problem it solves
When the wattage of an approved bulb is changed, nobody is told. The product stays approved, the old specification stays in the channels, and the change is found when a customer complains.
The concept explained
A check at entry protects the format of a value, but some changes need a person to look at them, or another job to run. When that depends on someone remembering, it is often missed. An Item Trigger makes the follow-up part of the change itself: when a chosen feature changes, perhaps only on approved products, Perfion sets a status, updates another value or runs an Action, whether it came in through the grid, the Item Editor, Compare, an import or the API. A comment on the item, with the right colleague tagged, carries the question to them.
Everyday analogy
A courier’s tracking message. The parcel is scanned, and the message goes out by itself; nobody has to remember to send it.
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
Item Triggers react to feature changes or to items being created or deleted, with optional conditions, and respond, for example by updating a feature value or running an Action. They fire on changes in the grid, the Item Editor and Compare, and through imports and the API. Comments tag users with @ and notify them in Perfion and, if they choose, by email.
The wattage of an approved bulb changes. A trigger sets Status to Review, and a comment tags the product manager.
10 Best Practices for Validation and Business Rules in Perfion
Each practice says what good data governance looks like and what it costs to ignore it. Setting them up for your team is what BPAS consultants do.
-
01Give every rule a help text that explains it
The rule
Every feature with a rule has a help text that says in plain words what is expected, such as “HSN code: 8 digits, numbers only”.
Risk if ignored
Editors see an alert without knowing what the rule wants, try again by guesswork, and then ask someone else.
Get it right with BPAS
Not sure this is in place for your team? Talk to a BPAS consultant.
Talk to BPASRelated:Concept 02Vocabulary: Help text
-
02Make a rule hard only when a value must never be wrong
The rule
Hard rules are kept for values that must never be wrong, such as tax codes and barcodes. House style guidelines, such as title length, are soft rules.
Risk if ignored
When every guideline blocks the work, editors work around the rules, and the rules that matter lose their weight.
Get it right with BPAS
Not sure this is in place for your team? Talk to a BPAS consultant.
Talk to BPAS -
03Test every pattern against real values first
The rule
Each regular expression has been tried against real good and bad values from the range before it is switched on.
Risk if ignored
Perfion does not help write expressions, so an untested pattern can reject good values or let bad ones through.
Get it right with BPAS
Not sure this is in place for your team? Talk to a BPAS consultant.
Talk to BPASRelated:Capability: Pattern rulesVocabulary: Regular expression
-
04Hold measurements in Number features
The rule
Weights, wattages and dimensions are held in Number features, so a number range can check them.
Risk if ignored
Measurements held as text, such as “9W”, can only be checked by a pattern, and the range check is lost.
Get it right with BPAS
Not sure this is in place for your team? Talk to a BPAS consultant.
Talk to BPAS -
05Review existing values when a rule is added
The rule
When a rule is added to a feature that already holds values, the old values that break it are found and corrected.
Risk if ignored
Old invalid values stay in the data, marked red or yellow, and keep reaching channels while only new values are held to the rule.
Get it right with BPAS
Not sure this is in place for your team? Talk to a BPAS consultant.
Talk to BPASRelated:Concept 04FAQ 03
-
06Correct list values on the list, not on products
The rule
Invalid values in a pick list are corrected on the list item, which corrects every product that uses it.
Risk if ignored
Products that use an old list value are not marked invalid, so a product-by-product hunt misses them and takes far longer.
Get it right with BPAS
Not sure this is in place for your team? Talk to a BPAS consultant.
Talk to BPASRelated:Concept 03Guide 02: Feature Data
-
07Check copied items for marked values
The rule
The team knows that copying items does not check rules, and looks for red and yellow values on copied items before they are released.
Risk if ignored
A copied product carries its source’s invalid values into the range, unnoticed.
Get it right with BPAS
Not sure this is in place for your team? Talk to a BPAS consultant.
Talk to BPASRelated:Concept 04FAQ 05
-
08Read the import log for warnings
The rule
After each import, soft rule warnings in the log are read and followed up, and rejected files are corrected at the source.
Risk if ignored
Soft invalid values come in with the import and stay there, because nobody opened the log.
Get it right with BPAS
Not sure this is in place for your team? Talk to a BPAS consultant.
Talk to BPAS -
09Keep triggers named, described and in priority order
The rule
Every Item Trigger has a clear name and description, conditions that keep it to the items it is meant for, and a priority agreed with any trigger that changes the same feature.
Risk if ignored
Triggers overrule each other or fire on items they were never meant for, and status changes appear that nobody can explain.
Get it right with BPAS
Not sure this is in place for your team? Talk to a BPAS consultant.
Talk to BPAS -
10Raise product questions as comments on the item
The rule
Questions about a product are asked as comments on the item, with the people who must answer tagged, so the question and the answer stay with the product.
Risk if ignored
Questions sit in email threads and chat groups, away from the product, and the answers are lost when people move on.
Get it right with BPAS
Not sure this is in place for your team? Talk to a BPAS consultant.
Talk to BPASRelated:Capability: Comments and notificationsVocabulary: Notification
Data governance self-audit: how many are in place today?
Tick each of the ten practices above that your product team 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 lighting brand, with every code and value checked by hand
A lighting brand makes about 1,200 products, LED bulbs, battens, panels and downlights, and sells them through distributors, its own web shop, two marketplaces and modern trade. Orders, stock and invoicing are in the ERP. Product data is kept in spreadsheets and checked by two reviewers when they have time.
The Operational Challenge
HSN codes are typed with six digits or a space in the middle, EANs are pasted with twelve digits, and one bulb’s wattage is entered as 90 instead of 9. The errors are found by a marketplace, a distributor or the finance team, weeks later.
When an approved product’s wattage changes, nobody is told. Last quarter, 35 listings went out with an old specification, and questions about products were scattered across email threads and chat groups.
- Codes typed in different formats
- Wrong values found by channels, weeks later
- Changes to approved products not reviewed
- Questions lost in email threads
The Financial Transformation
In Perfion, a business rule on each key feature checks values as they are entered. HSN codes must have eight digits and EANs thirteen, as hard rules, and wattage must be greater than 0 and at most 50. Web titles longer than 150 characters get a soft warning, and every rule has a help text, so editors see at once what is expected.
An Item Trigger sets an approved product back to Review whenever its wattage changes, and questions are asked as comments on the item, with the product manager tagged.
- Codes checked as they are entered
- Supplier files rejected with the reasons
- Changes to approved products sent to review
- Questions answered on the item
| Cost line | Before (per month) | After (per month) | Difference (per year) |
|---|---|---|---|
| Finding and correcting wrong codes and values | ₹ 70,000 | ₹ 15,000 | ₹ 6,60,000 |
| Fixing listings rejected by channels | ₹ 60,000 | ₹ 15,000 | ₹ 5,40,000 |
| Chasing reviews and answers by email and phone | ₹ 45,000 | ₹ 15,000 | ₹ 3,60,000 |
| Total | ₹ 1,75,000 | ₹ 45,000 | ₹ 15,60,000 |
See your own product data checked as it is entered in Perfion.
Book a data quality 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 from data checked at entry: one rule set, three answers
-
Promoter & CXOs
Can we trust the product data our customers see?
Codes and values are checked as they are entered, and changes to approved products go back to review, so errors are stopped before channels and distributors see them.
-
Product Data Manager
Can our data standards enforce themselves?
Business rules turn the standards into checks on each feature, hard where a value must never be wrong and soft for guidelines, and Item Triggers send changed products back to review.
-
Product Executive
How do I know a value is right before I save it?
The rule tells you at once. A help text explains what is expected, and a question for the product manager goes on the item as a comment, not in an email.
Data Governance Vocabulary and Definitions
From rules that check each value, to triggers that act on changes and comments that reach the right person. Each term shows what it means, why it matters, and a household comparison.
-
Business rule
Validation · rulesSet on the feature
Operational definition
An extended rule on a feature that limits the values users can set beyond what the feature type defines, such as 50 characters at most in a String feature.
Why it matters in Perfion
Set on Number, String and Text features, and enforced through all user interfaces and through import.
Everyday analogy
A railway ticket gate that checks every ticket at the entrance.
See it in action:Concept 01 under Core Concepts →
-
Regular expression
Validation · rule typeRegEx
Operational definition
A pattern a value must match, such as exactly eight digits, or a code that starts with AB or CD followed by two digits.
Why it matters in Perfion
The RegEx rule type checks lengths, characters and code formats. The Perfion interface does not help write the expression.
Everyday analogy
A form box marked for exactly six digits, like a PIN code.
See it in action:Pattern rules under Capabilities →
-
Number rule
Validation · rule typeNumber features
Operational definition
A rule type for Number features that sets a range of allowed values with one or two operators, such as greater than 0 and at most 100.
Why it matters in Perfion
No regular expression is needed. Two contradictory operators make every value invalid.
Everyday analogy
A lift’s load limit: anything up to the limit goes, anything over it is refused.
See it in action:Number ranges under Capabilities →
-
Hard validation
Validation · enforcementMarked red
Operational definition
Enforcement that rejects illegal values. The user is told the rule and asked to change the value.
Why it matters in Perfion
Values from before the rule that break it are marked red. An import with hard invalid values is rejected.
Everyday analogy
A red traffic light: you stop.
See it in action:Concept 02 under Core Concepts →
-
Soft validation
Validation · enforcementMarked yellow
Operational definition
Enforcement that allows illegal values, but warns the user before saving and asks them to confirm.
Why it matters in Perfion
Accepted values stay marked yellow. An import with only soft invalid values goes ahead and lists them in the log.
Everyday analogy
An amber light: you are warned, and the decision is yours.
See it in action:Concept 02 under Core Concepts →
-
Help text
Features · guidanceShown with alerts
Operational definition
The feature’s explanation for users. With a rule, it is shown wherever users try to enter an invalid value.
Why it matters in Perfion
It is optional, but Boyum calls it important: it turns an alert into an explanation of the standard.
Everyday analogy
The instruction printed beside a box on a bank form.
See it in action:Hard and soft rules under Capabilities →
-
Item Trigger
Automation · reactionsPerfion 2021-R2 and later
Operational definition
A defined scenario in which a change to an item, or an item being created or deleted, makes Perfion respond by itself.
Why it matters in Perfion
It is set on one selectable base feature, can have conditions, and updates a feature value or runs an Action. An administrator activates Item Triggers.
Everyday analogy
A courier’s tracking message, sent by itself when the parcel is scanned.
See it in action:Concept 05 under Core Concepts →
-
Activity
Item Triggers · responseSet a value or run an Action
Operational definition
What an Item Trigger does when it fires, such as updating Status to Review, or running an Action.
Why it matters in Perfion
Running an Action is offered when Actions are installed, and needs the Application Server to be running.
Everyday analogy
The “then” in “if this happens, then do that”.
See it in action:Item Triggers under Capabilities →
-
Trigger log
Item Triggers · historySix statuses
Operational definition
The log of Actions run by Item Triggers, with the status of each run and its execution log.
Why it matters in Perfion
Statuses are New, Queued, Started, Success, Failed and AbnormalTermination, so a failed run can be found and followed up.
Everyday analogy
The delivery history in a courier app.
See it in action:Triggers that run Actions under Capabilities →
-
Notification
Collaboration · alertsBell and email
Operational definition
An alert to a user tagged with @ in a comment. The bell in Perfion turns red, and the notification links straight to the item.
Why it matters in Perfion
Users who choose email notifications also get an email with the text and a direct link to the Item Editor for that product.
Everyday analogy
A note left with the doorbell: you know someone called, and why.
See it in action:Comments and notifications under Capabilities →
Validation and business rules: questions product teams ask
Short answers, each with a link to the part of this guide that explains it.
-
A rule on a feature that limits the values users can set beyond what the feature type allows, such as an HSN code of exactly eight digits or a wattage of at most 50. Rules are set on Number, String and Text features and are checked in every user interface and in imports.
More on Concept 01 -
A hard rule rejects an invalid value, so it cannot be saved. A soft rule warns the user and asks them to confirm before saving. Values that break hard rules are marked red, and values that break soft rules are marked yellow.
More on Concept 02 -
They stay as they are and are marked red or yellow. Saving in the Item Editor does not recheck them, so new work can still be saved. On pick lists, products that use an old invalid value are not marked: Boyum’s intent is that the value is corrected once, on the list item.
More on Concept 03 -
Yes. An import with hard invalid values is rejected, and the user is told why. An import with only soft invalid values goes ahead, and the log lists them. Values that are not picked from a list are always checked; new list values are checked when the import is allowed to create them.
More on Rules on every route in -
No. Copying items, children and relations does not enforce rules, so invalid values, hard or soft, are copied as they are. Check copied items for marked values before they are released.
More on Practice 07 -
React to changes in chosen features, or to an item being created or deleted, and then update a feature value, such as setting Status to Review, or run an Action. Conditions can limit it, for example to approved products. Triggered Actions are logged with their status, so a failed run can be found.
More on Concept 05 -
Yes. Business rules, Item Triggers and comments are part of Perfion itself, so this guide applies whichever ERP your product data comes from. What changes from one ERP to another is the integration that brings ERP data into Perfion.
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 product data checked and governed in Perfion
See your own codes and values checked as they are entered, hard where they must never be wrong and soft for guidelines, and every change sent to the right person. 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→