Skip to main content

BPAS

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

Users and Security

Perfion PIM · Complete Feature Guide

Users and Security Perfion Access Control Guide

Who can log in, what each person can see and change, and how integrations connect: user groups, rights in layers, roles, password rules and a service account built for the API.

See It for Your Teams What this guide covers

Users and security in Perfion decide who can log in, what each person can see and change, and how other systems connect. Every user belongs to one or more user groups, and rights are set in layers: sections, features placed in a security group, items through Feature Item Security, and languages through language permissions. Roles open functions such as imports and reports, password requirements protect each login, and the Service Account connects integrations without using a user licence.

Written for product data and IT teams · 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
User Rights, User and Group Management, Role-based Access, Login Options and Service Account
Where
User and group management, security groups and login options, managed by administratorsUser groupsSecurity groupsRolesPassword requirements are set in the web client
Used by
Administrators, product data managers and ITOnly Administrators manage users, groups and security
Works with
FeaturesLanguagesAI roles
Documented layers of access
Four layers of rights, with roles and login rules on topSectionsFeatures, by security groupItems, by Feature Item SecurityLanguages
How It Works

How users and security work in Perfion, from people and groups to protected logins

People join groups. Groups get sections, rights on each security group, roles and languages. Logins follow your password rules, and integrations come in through their own account.

  1. Put every person in groups

    Each person has their own user and joins one or more user groups. Administrators, Super Users and Users are built in; new groups start with no rights, and a user in several groups gets the highest privileges.

  2. Open the right areas

    Each group opens only the sections its work needs, such as Products. Features, where the data model is changed, stays with Administrators.

  3. Secure features and items

    Each feature sits in a security group with read, write and delete rights per user group, and Feature Item Security narrows them to items with certain values.

  4. Grant roles and languages

    Roles open functions such as imports, reports and actions, and language permissions decide which languages each user can edit.

  5. Protect logins and integrations

    Password requirements and a lock after failed attempts protect every login, and integrations connect through the Service Account.

An illustration, not a screenshot: user groups, rights on each security group, roles for one group, the Service Account for integrations, and the login rules.
Shared Logins vs Perfion Security

Shared logins vs Perfion security: what changes when everyone has the right access

With shared logins, anyone who knows the password can change anything, and nobody can say who did. In Perfion, each person has their own user, rights come from groups and layers, and integrations have their own account.

Shared logins and spreadsheets compared with Perfion's user groups, security groups, Feature Item Security, roles, password requirements and Service Account, as described in Boyum IT Solutions' Perfion documentation.
Task Shared logins and spreadsheets Perfion users and security
Who logs in A few shared logins, passed around the team. Each person has their own user, in one or more user groups.
Who changes which fields Anyone with the login or the file. Each feature sits in a security group, with read, write and delete rights for each user group.
Who changes which products Every team can change every product. Feature Item Security gives a team rights only to products with certain values, such as its own categories.
Translators Full access, to fix one language. Edit rights to their own languages only, set by language permissions.
Bulk imports Anyone can overwrite data in bulk. Roles decide who can import, import without validation, or export from the grid.
Integrations Run on a person’s login. A built-in Service Account for API integrations, outside the licence count.
Passwords Whatever each person chooses, kept for years. Length, character, expiry and lockout rules set by administrators.
Leavers Old logins stay active for months. Users are deactivated, and can be activated again if they return.

See how access for your own teams would be set up in Perfion.

See it for your teams
Capabilities in Depth

Perfion security capabilities: eight ways to give every team the right access

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

Operational Reality (Capabilities)

Each person has their own user, and every user is a member of one or more user groups. Three groups are built in and cannot be deleted: Administrators, with all rights; Super Users, who can edit all items and values but cannot change the data model or do administrative tasks; and Users, with no predefined rights. New groups start with the same privileges as Users. A user in several groups always gets the highest privileges of those groups. Users can also come from Active Directory, and a Windows domain user ID lets a user log in automatically.

  • Three built-in groups that cannot be deleted
  • New groups start with no rights
  • Highest privileges win across groups

Executive ROI Value

Access is organised by team, so a new joiner gets the right access by joining the right groups, and every right can be explained.

  • Faster onboarding
  • Access you can explain

Operational Reality (Capabilities)

The first layer decides which sections, the main areas of Perfion such as Products, each group can open. Features, where the data model is changed, is for Administrators only. Super Users can open Feature Data and every other section. For all other groups, access to each section is granted on purpose, group by group.

  • Access to each section, per group
  • Features for Administrators only
  • Super Users open every other section

Executive ROI Value

People see the areas their work needs and nothing else, which keeps screens simple and the data model safe.

  • Simpler screens
  • Data model protected

Operational Reality (Capabilities)

Each feature is placed in a security group, whatever tab it appears on. For each security group, rights are set per user group: to read, write and delete, separately for items and for values. A marketing group can hold full rights on marketing features while other users can only read them. Security groups are not the same as user groups: one decides which features, the other which people.

  • Security set feature by feature
  • Rights for each user group
  • Items and values set separately

Executive ROI Value

Each team changes only the product data it is responsible for, and everyone else can still see what they need.

  • Clear data ownership
  • Fewer wrong edits

Operational Reality (Capabilities)

Feature Item Security gives or restricts access to items that have specific values on a selectable feature. With Category, one team can be given edit rights to products in Switches, and another to products in MCBs. Rights can cover the value itself, such as the category, and the items that carry it, such as its products. It works hand in hand with security groups: it only applies to values the same users can already change there.

  • Access by the value of a selectable feature
  • The value itself and the items that carry it
  • Within the rights of security groups

Executive ROI Value

Teams that own different product ranges work side by side in one record without changing each other’s products.

  • Range ownership
  • No cross-team overwrites

Operational Reality (Capabilities)

Each user is given the active languages they work in, with an edit right for each language and a separate edit right for features that are not localizable. A Spanish translator can manage Spanish values and not English ones. A user who can edit in at least one language, or edit the non-localized features, is an Editor; other users are Readers, and the licence sets how many of each can be active at the same time.

  • An edit right for each language
  • A separate right for non-localized features
  • Editors and Readers counted by the licence

Executive ROI Value

Translators and market teams work only on their own languages, and editing licences go to the people who change data.

  • Safe translation work
  • Licences used well

Operational Reality (Capabilities)

Roles grant access to functions: executing, designing and exporting via reports; exporting data from the grid; importing data, with or without validation; importing and exporting actions; executing actions; editing schedules; the Log, the Audit Log and the Recycle Bin; the API tool; Feature Data; managing AI integration; and managing items, custom pages, users and organisations in the Content Store. A role can be given directly to a user or to a group, whose members inherit it. Administrators always have every role.

  • Given to users or to groups
  • Default roles for new users, none for new groups
  • Administrators always have every role

Executive ROI Value

Powerful functions, such as importing without validation, stay with the few people trained to use them.

  • Bulk changes controlled
  • Functions matched to jobs

Operational Reality (Capabilities)

Administrators set password requirements in the web client: a minimum length, and whether lowercase, uppercase, numeric and special characters are required. Passwords can expire after a set number of days, and a change can be forced at the next login, for one user or for all. New rules can apply to everyone at once or at each user’s next password change. After a set number of failed login attempts, the account is disabled until an administrator enables it again.

  • Length and character rules
  • Expiry and forced change
  • A lock after failed attempts

Executive ROI Value

Logins to the product record meet the company’s IT policy, and password guessing stops after a few attempts.

  • IT policy applied
  • Accounts protected

Operational Reality (Capabilities)

Since 2025-R1, every user has an access type: Clients only, Clients & Service, or Service only. A built-in Service Account, in every installation, is used for API integrations. It cannot be deleted or modified and is locked to Service only. It and the Admin user do not count against the licence, though custom users with service-only access do. Perfion checks the access type at login and refuses the wrong channel with a message.

  • Clients only, Clients & Service, Service only
  • A built-in Service Account for the API
  • Admin and Service Account outside the licence count

Executive ROI Value

Integrations run on an account made for them, so they do not use up user licences or depend on one person’s password.

  • Licences kept for people
  • Integrations that keep running
Core Concepts

5 Core Concepts of Access You Can Explain

The first two are about structure: groups and layers. The third is about pick lists, the fourth about integrations, and the last about people over time.

  1. Concept 01 · Rights belong to groups

    Give Rights to Groups, Not to People

    The product data problem it solves

    Rights were set one person at a time. Two years later, nobody can say why one executive can delete products and her colleague in the same team cannot, and every new joiner waits a week for access.

    The concept explained

    Rights set user by user drift apart and cannot be explained. In Perfion, every user belongs to one or more user groups, and rights and roles are given to the groups. A person gets what their groups allow, so a new joiner is ready as soon as they join the right groups. When a user is in two groups, Perfion always gives the highest privileges of the two, which keeps the model simple to reason about.

    Everyday analogy

    Office access cards by department. The card for Accounts is set up once, and every new accountant gets it on day one.

    In Perfion

    Administrators, Super Users and Users are built-in groups that cannot be deleted. New groups start with the same privileges as Users. Users inherit roles from their groups, and a group cannot be deleted while it has members, including inactive users.

    Related:
    Give rights to groups, not to peopleLeft: four users, Priya, Arjun, Kavya and Kiran. Centre: three user groups. Priya and Kiran are in Marketing, Arjun is in Technical, and Priya and Kavya are in the catalogue team. Right: the rights each group holds: Marketing writes marketing content and reads technical data, Technical writes technical data, and the catalogue team writes technical data. Bottom: Priya is in Marketing and the catalogue team; Marketing reads technical data and the catalogue team writes it, so Priya can write it, because a user in several groups gets the highest privileges.People join groups; groups hold the rightsPriyaArjunKavyaKiranUser groupMarketingUser groupTechnicalUser groupCatalogue teamMarketing content: writeTechnical data: readTechnical data: writeTechnical data: writePriya is in Marketing and the catalogue teamMarketing reads technical data; the catalogue team writes it.Priya can write it: the highest right wins.
    Users join groups and groups hold the rights: Priya is in Marketing and in the catalogue team, and gets the higher right of the two.
  2. Concept 02 · Each layer narrower

    Set Rights in Layers, from Sections to Languages

    The product data problem it solves

    A content agency is given a login to update marketing texts on lighting products. With the same login it can also change the rated current of every MCB and the Arabic texts of the export team.

    The concept explained

    Access in Perfion is set in layers, each narrower than the one before. Sections decide which areas a group can open. Security groups decide who can read, write or delete each set of features. Feature Item Security narrows that to items with certain values, such as a team’s own categories. Language permissions decide which languages a user can edit. Designed together, the layers give each team exactly the data it owns, and nothing more.

    Everyday analogy

    A large office building. The gate pass, the floor, the department and the filing cabinet each need their own permission, and a visitor gets only the first.

    In Perfion

    Features, where the data model is changed, is reserved for Administrators; access to other sections is set per group. Each feature is placed in a security group with rights for each user group. Feature Item Security works hand in hand with those rights: it only applies to values a user can already change.

    Related:
    BPAS method · toolDeploy EnterpriseDesign before configurationThe data model is designed and signed off before anything is configured: the Design phase of toolDeploy Enterprise.
    Set rights in layers, from sections to languagesFour bands, each narrower than the one above. Sections: which areas a group can open; Features is for Administrators only. Features, through security groups: read, write or delete on each set of features. Items, through Feature Item Security: only products with certain values, such as a team's own categories. Languages: which languages each user can edit. Bottom: each layer narrows the one above, and Feature Item Security only applies to values a user can already change through security groups.Each layer narrows what a group can changeSectionsWhich areas a group opens. Features, where the model changes: Administrators onlyFeatures · security groupsRead, write or delete on each set of featuresItems · Feature Item SecurityOnly products with certain values, such as own categoriesLanguagesWhich languages each user can editDesigned together, not one by oneFeature Item Security only applies to values a user can already change through security groups.
    Sections, then features, then items, then languages: each layer narrows what a group can change.
  3. Concept 03 · The list and its use

    Separate Rights to Lists from Rights to Values

    The product data problem it solves

    A product executive only needs to set the finish on new switches. Because she can edit finishes, she also adds “Gold”, “Golden” and “Gold finish” to the finish list, and the web shop filter now shows all three.

    The concept explained

    In Perfion, an item is a container for values. Every entry in a pick list, such as the finish Gold, is an item, and the finish chosen on a product is a value. Rights on a security group are set separately for items and for values. So one group can maintain the finish list, another can only choose finishes on products, and everyone else can see both without changing either.

    Everyday analogy

    A restaurant menu. The chef decides what is on the menu; the waiter takes orders only from it.

    In Perfion

    With full rights on items and values for a feature such as Colour, a group can create, edit and delete entries in the Colour list and set colours on products. With read rights only, users see the list and each product’s colour but cannot change either.

    Related:
    Separate rights to lists from rights to valuesLeft: the Finish pick list, whose entries White, Grey and Gold are items. Right: three switches, each with a finish chosen from the list; those choices are values. Bottom left: the Marketing group, with write rights on items and values, can add a finish to the list and set the finish on products. Bottom right: other users, with read rights only, see the list and each product's finish but cannot change either.The list is items; the choice on a product is a valueFinish · pick listEach entry is an itemWhiteGreyGoldProductsThe finish chosen is a valueSW-6A-01WhiteSW-6A-02GreySW-16A-01GoldMarketing · writeAdds a finish to the list, andsets the finish on products.Other users · readSee the list and each product’sfinish, and change neither.
    One group maintains the finish list; product teams choose from it; everyone else can only read.
  4. Concept 04 · One door for people, one for systems

    Keep People and Integrations Apart

    The product data problem it solves

    The web shop feed runs on the product manager’s login. When her password changes before she goes on leave, the feed stops, and new products do not reach the shop for four days.

    The concept explained

    An integration that runs on a person’s login uses up a user licence, depends on that person’s password and stops with their account. Since 2025-R1, every user in Perfion has an access type: Clients only, Clients & Service, or Service only. A built-in Service Account handles API integrations without counting against the licence, and people can be kept to the clients, where an external API call with their login is refused.

    Everyday analogy

    A shared orders mailbox for the company. Orders keep arriving when one employee is on leave, which they would not if they went to her personal inbox.

    In Perfion

    The Service Account is in every installation since 2025-R1, cannot be deleted or modified, is a member of the Administrators group and is locked to Service only. Admin and the Service Account are outside the licence count; custom users with service-only access count. Users imported from Active Directory start as Clients only.

    Related:
    Keep people and integrations apartLeft: people, Priya and Arjun, set to Clients only, work in the Perfion clients. Centre: Perfion checks the access type at login. Right: the ERP link uses the built-in Service Account, Service only and outside the licence count, and a web shop feed uses its own service-only user, which counts in the licence. Bottom: an integration on a person's login needs Clients and Service access, uses that person's licence and stops with their password or account.One door for people, another for integrationsPriyaClients onlyArjunClients onlyWindows and web clientsPerfionAccess type ischecked at loginWrong channel: refusedERP linkService AccountNot countedWeb shop feedOwn service-only userCounts in licenceService only, through the APIAn integration on a person’s loginIt needs Clients & Service access, takes a user licence, and stops whenthat person’s password changes or their user is deactivated.
    People use the clients; integrations use the Service Account or service-only users, each through its own door.
  5. Concept 05 · Join, move, leave

    Manage Access as People Join, Move and Leave

    The product data problem it solves

    An executive who left in March still has an active login in August. Her password never expired, and nobody noticed until product names changed under her user.

    The concept explained

    Access is not set once. People join, change teams and leave, and logins are tried from outside. In Perfion, a person’s rights change with their group memberships. Password requirements set the length, the characters and the expiry of passwords, a new password can be forced at the next login, and too many failed logins lock the account until an administrator enables it again. A user who has created items cannot be deleted; deactivating removes access, and the user can be activated again later.

    Everyday analogy

    Hotel key cards. Issued at check-in, re-coded when you change rooms, and stopped at check-out.

    In Perfion

    Administrators set a minimum length; lowercase, uppercase, numeric and special characters; expiry in days; a forced change for one user or all users; and a lock after a set number of failed attempts. New requirements can apply immediately for all users or at the next password change.

    Related:
    From BPAS · prodRecord newsletterprodRecordKeeping the record straight.One product data practice every month, written in plain English for product data teams.
    Manage access as people join, move and leaveThree stages and a safeguard. Join: the user is created in the right groups and must change the password at first login. Move: group memberships change and rights follow the groups. Leave: the user is deactivated, which removes access, and can be activated again. Alongside them, Locked: after too many failed login attempts the account is disabled until an administrator enables it. Bottom: password rules for length, characters and expiry apply throughout, and a user who has created items cannot be deleted, only deactivated.Access changes with people, from first day to lastJoinIn the right groups;new password at loginMoveGroups change;rights followLeaveDeactivated; can beactivated againLockedFailed logins; anadmin re-enablesThroughout: password requirementsMinimum length, character types and expiry in days, set by administratorsDeactivate, do not deleteA user who has created items cannot be deleted. Deactivating removes access.
    Join with a forced password change, move by changing groups, leave by deactivation; failed logins lock the account.
Best Practices

10 Best Practices for Users and Security in Perfion

Each practice says what well-governed access looks like and what it costs to ignore it. Designing it for your teams is what BPAS consultants do.

  1. 01Give every right through a group

    Structure · Groups

    The rule

    Rights and roles are given to user groups that match real teams, never to individual users one by one.

    Risk if ignored

    Each person’s access is different and unexplained, and new joiners wait while rights are pieced together.

    Get it right with BPAS

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

    Talk to BPAS

    Related:Concept 01Vocabulary: User group

  2. 02Keep Administrators and Super Users to a few named people

    Structure · Privilege

    The rule

    Only a few named people are Administrators or Super Users; everyone else works in groups with the rights their job needs.

    Risk if ignored

    Many people can change the data model or delete items, and one mistake reaches every channel.

    Get it right with BPAS

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

    Talk to BPAS

    Related:Vocabulary: Administrators, Super Users and UsersCapability: Users and groups

  3. 03Place every feature in a security group on purpose

    Features · Security

    The rule

    Every feature belongs to a security group chosen by who owns the data, such as marketing, technical or compliance.

    Risk if ignored

    Technical and compliance values are open to anyone who can edit marketing text.

    Get it right with BPAS

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

    Talk to BPAS

    Related:Concept 02Vocabulary: Security group

  4. 04Give every pick list one owning group

    Data · Lists

    The rule

    Each pick list is maintained by one owning group, and other teams choose from it on products.

    Risk if ignored

    Lists fill with near-duplicate entries, and filters and reports split one value into several.

    Get it right with BPAS

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

    Talk to BPAS

    Related:Concept 03Guide 02: Feature Data

  5. 05Let teams change only the products they own

    Items · Ownership

    The rule

    Where teams own different product ranges, each team can change only the products in its own categories.

    Risk if ignored

    One team overwrites another team’s products, and nobody owns the result.

    Get it right with BPAS

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

    Talk to BPAS

    Related:Capability: Feature Item SecurityVocabulary: Feature Item Security

  6. 06Keep translators to their own languages

    Languages · Scope

    The rule

    Translators edit only the languages they translate, and only localized features.

    Risk if ignored

    A translator changes the source text or a technical value while fixing one language.

    Get it right with BPAS

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

    Talk to BPAS

    Related:Capability: Language permissionsGuide 07: Languages and Translation

  7. 07Keep powerful roles with a few people

    Roles · Risk

    The rule

    Roles such as importing without validation, the Recycle Bin, the API tool and editing schedules are held only by the people who need them.

    Risk if ignored

    An unchecked import overwrites values on thousands of products in a single run.

    Get it right with BPAS

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

    Talk to BPAS

    Related:Capability: Role-based accessVocabulary: Role

  8. 08Run integrations on the Service Account, not a person

    Integrations · Access

    The rule

    Every integration uses the Service Account or a service-only user, and people’s logins are kept to the clients.

    Risk if ignored

    An integration stops when someone changes a password or leaves, and it uses up a user licence.

    Get it right with BPAS

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

    Talk to BPAS

    Related:Concept 04Vocabulary: Service Account

  9. 09Match login rules to your IT policy

    Logins · Policy

    The rule

    Password length, character rules, expiry and lockout in Perfion match the company’s IT security policy.

    Risk if ignored

    Weak passwords that never change protect the whole product record.

    Get it right with BPAS

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

    Talk to BPAS

    Related:Capability: Password and login rulesVocabulary: Password requirements

  10. 10Deactivate leavers on their last day, and review access

    Lifecycle · Review

    The rule

    Leavers are deactivated on their last day, and group memberships and roles are reviewed at regular intervals.

    Risk if ignored

    Former staff and old agency users keep access to product data for months.

    Get it right with BPAS

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

    Talk to BPAS

    Related:Concept 05FAQ 04

Self-Audit · 10 Best Practices

Access 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 an access review

Nothing you tick is stored or sent.

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

Illustrative scenario: an Indian electrical products maker, with three shared logins

An electrical products maker has about 3,500 products: switches, MCBs, wires and LED lighting. About 30 people work on product data, in product, marketing and technical teams, an export team with Arabic and French translators, and an outside content agency. Orders, stock and invoicing are in the ERP, and product data reaches a web shop and two marketplaces.

The Operational Challenge

Everyone works through three shared logins, one of which can change everything. The agency can edit technical values as easily as marketing texts. The ERP link runs on an IT executive’s own login, and it stopped for two days when his password changed. A product executive who left in March was still active in August.

Last year an import overwrote the rated current on about 600 MCBs, and nobody could say who ran it.

  • Three shared logins, one with every right
  • An agency able to change technical data
  • An integration on one person’s login
  • Leavers still active months later

The Financial Transformation

In Perfion, every person has their own user in the right user groups. Features are placed in security groups for marketing, technical and compliance data, and Feature Item Security keeps each product team to its own ranges. Translators edit only Arabic or French, and only two people hold the role to import without validation.

The ERP link and the web shop feed run through the Service Account. Password requirements match the company’s IT policy, leavers are deactivated on their last day, and group memberships are reviewed every quarter.

  • Every change made by a named user
  • Each team on its own data and ranges
  • Integrations independent of people
  • Access that follows IT policy
Illustrative figures for a typical Indian electrical products maker 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)
Finding and correcting wrong or unauthorised changes₹ 1,20,000₹ 20,000₹ 12,00,000
Integration stoppages and catch-up work₹ 60,000₹ 8,000₹ 6,24,000
Access administration and audit preparation₹ 40,000₹ 12,000₹ 3,36,000
Total₹ 2,20,000₹ 40,000₹ 21,60,000
Illustrative saving a year₹ 21,60,000Same figures as the table, not a client result

See how your own teams, agencies and integrations would be secured in Perfion.

Book an access 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 from access you can explain: one record, three answers

  • Promoter & CXOs

    Can we trust who changes our product data?

    Every change is made by a named user, with rights the business decided, so the product record that reaches dealers, marketplaces and export markets is protected.

  • Product Data Manager

    Can each team work only on what it owns?

    Security groups, Feature Item Security and language permissions give each team, agency and translator exactly the data it is responsible for.

  • IT Manager

    Do logins and integrations meet our IT policy?

    Password requirements, expiry and lockout follow company policy, and integrations run through the Service Account instead of a person’s login.

Vocabulary

Users and Security Vocabulary and Definitions

From groups and security groups to roles, access types and login rules. Each term shows what it means, why it matters, and a household comparison.

  1. User group

    Security · people

    One or more per user

    Operational definition

    A named set of users that rights and roles are given to. Every user is a member of one or more groups.

    Why it matters in Perfion

    A user in several groups always gets the highest privileges, and inherits the roles of every group.

    Everyday analogy

    A department’s access card: every member opens the same doors.

    See it in action:Concept 01 under Core Concepts →

  2. Administrators, Super Users and Users

    Security · built in

    Cannot be deleted

    Operational definition

    Perfion’s three built-in groups. Administrators have all rights; Super Users can edit all items and values but cannot change the data model or administer; Users have no predefined rights.

    Why it matters in Perfion

    New groups start with the same privileges as Users, so every right beyond that is given on purpose.

    Everyday analogy

    The owner, the manager and the new staff member on their first day.

    See it in action:Users and groups under Capabilities →

  3. Security group

    Security · features

    Rights set in Information Groups

    Operational definition

    The group a feature is placed in for security. Each user group’s rights on it, to read, write or delete items and values, are set in Information Groups.

    Why it matters in Perfion

    Security is set feature by feature, whatever tab the feature appears on. Security groups are not the same as user groups.

    Everyday analogy

    Filing cabinets by department: who may open each one is decided once.

    See it in action:Concept 02 under Core Concepts →

  4. Feature Item Security

    Security · items

    Set on a selectable feature

    Operational definition

    Rights that depend on a value of a selectable feature, such as edit rights to the products in one category only.

    Why it matters in Perfion

    It covers the value itself and the items that carry it, and applies only to values a user can already change through security groups.

    Everyday analogy

    A key to one aisle of the warehouse, not the whole building.

    See it in action:Feature Item Security under Capabilities →

  5. Language permissions

    Security · languages

    Set on each user

    Operational definition

    The languages each user works in, with an edit right per language and a separate edit right for non-localized features.

    Why it matters in Perfion

    A translator can edit Arabic without being able to change English or technical values.

    Everyday analogy

    Handing a translator the Arabic pages of a brochure, not the whole print file.

    See it in action:Language permissions under Capabilities →

  6. Role

    Security · functions

    Role-based Access

    Operational definition

    A right to use a function, such as importing data, designing reports, executing actions or managing AI integration. Given directly to a user or through a group.

    Why it matters in Perfion

    New users start with default roles for reports, exporting from the grid and importing; new groups start with none. Administrators always have every role.

    Everyday analogy

    Signing authority: many staff, few who can approve a payment.

    See it in action:Role-based access under Capabilities →

  7. Editor and Reader

    Licence · user type

    Counted by the licence

    Operational definition

    The two user types. A user who can edit in at least one language, or edit non-localized features, is an Editor; any other user is a Reader.

    Why it matters in Perfion

    The licence sets how many Editors and how many Readers can be active at the same time.

    Everyday analogy

    Library members who can borrow, and visitors who read in the hall.

    See it in action:Language permissions under Capabilities →

  8. Access type

    Security · channel

    From 2025-R1

    Operational definition

    Whether a user works in the Perfion clients, through the API, or both: Clients only, Clients & Service, or Service only.

    Why it matters in Perfion

    Service-only users are refused in the Windows client and the web and Supplier Portal; clients-only users cannot authenticate through external API calls.

    Everyday analogy

    A staff entrance and a goods entrance: each pass opens the door it is meant for.

    See it in action:Concept 04 under Core Concepts →

  9. Service Account

    Integrations · API

    Built in since 2025-R1

    Operational definition

    A built-in user for API integrations, in every installation since 2025-R1. It cannot be deleted or modified and is locked to Service only.

    Why it matters in Perfion

    It does not count against the user licence, so integrations do not use up places meant for people.

    Everyday analogy

    The company’s shared orders mailbox, not one employee’s inbox.

    See it in action:Practice 08 under Best Practices →

  10. Password requirements

    Security · login

    Set in the web client

    Operational definition

    The login rules administrators set: minimum length, character types, expiry, forced change, and locking an account after failed attempts.

    Why it matters in Perfion

    A locked account stays disabled until an administrator enables it again.

    Everyday analogy

    A bank locker whose code you change regularly, and which stays shut after a few wrong tries.

    See it in action:Password and login rules under Capabilities →

FAQ

Users and security: questions product and IT teams ask

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

  1. Yes. Each feature is placed in a security group, and each user group gets its own rights on it: to read, write or delete, separately for items and for values. A marketing team can change marketing texts and only read technical data, while the technical team does the reverse.

    More on Security groups

  2. Yes, with Feature Item Security on a selectable feature such as Category. It works together with security groups: a team can change only the values it already has write rights to, and only on products in the categories it has been given.

    More on Feature Item Security

  3. The user always gets the highest privileges. If one group can only read a set of features and the other can read, write and delete it, the user can read, write and delete. Roles are inherited from every group too.

    More on Concept 01

  4. A user who has created items, such as products, cannot be deleted. The user is deactivated instead, which removes their access, and can be activated again if they return. A group cannot be deleted while it still has members, including inactive users.

    More on Concept 05

  5. Not if they use the Service Account. Since 2025-R1, every installation has a built-in Service Account for API integrations, and it does not count against the licence; nor does the Admin user. Custom users with service-only access do count.

    More on Service Account

  6. Yes. Administrators set a minimum length, required character types, expiry in days, a forced change at next login, and a lock after a set number of failed attempts. A locked account stays disabled until an administrator enables it again.

    More on Password and login rules

  7. Yes. Users, groups, rights, roles and login rules 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 BPAS
Works Together With

See the right access for every team in Perfion

See how your teams, agencies, translators and integrations would each get the right access to your product data in Perfion. 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