--- title: "Users" description: "A non-technical overview of Users in RevCent, focused on how sub-user accounts are configured in the web app, how user types differ, and how permissions, abilities, and Organization assignment control visibility and access." type: "feature" company: "RevCent" canonical: "https://revcent.com/documentation/markdown/ecosystem/feature/User.md" relationships: - name: "Organization" url: "https://revcent.com/documentation/markdown/ecosystem/feature/Organization.md" technical_links: web_app: "https://kb.revcent.com/management/organization/user" --- # Users Users are web-app-only configurable sub-accounts within a main RevCent account. A User is not a customer, buyer, subscriber, or outside shopper. In this context, a User is someone who can log in to the RevCent web app under the main account with a specific role, permissions, abilities, and, when applicable, Organization-based visibility restrictions. The practical idea is: ```text Main RevCent Account ↓ Users = sub-accounts for staff or operators ↓ User type + permissions + abilities + Organization assignment determine access ``` Users are especially important for businesses that need multiple people to work inside RevCent without giving every person full account-owner access. --- ## Why Users Are a Feature Users are a feature because they are configurable account-level access records created and managed by the business inside the RevCent web app. They are not spawned by a sale, customer, transaction, AI thread, or payment event. Instead, they are intentionally configured to give staff, managers, or operators controlled access to the RevCent account. Conceptually: ```text Business creates or edits a User ↓ Business selects a user type ↓ Business assigns permissions and abilities when applicable ↓ Business assigns Organizations when required ↓ The User can access only what their configuration allows ``` This makes Users part of RevCent's account-management and access-control system. --- ## Web-App-Only Configuration Users are configured in the RevCent web app. A business can view Users, create a new User, edit an existing User, configure details, assign a user type, configure abilities, review activity, and set permissions from the web app. This ecosystem document treats Users as a web-app-only configurable feature. Any automation or documentation that references Users should understand the concept and respect the access model, while recognizing that Users are configured through the web app in this documentation. --- ## Technical Links | Area | Link | |---|---| | Web App | `https://kb.revcent.com/management/organization/user` | --- ## Core Purpose The core purpose of Users is to let the main RevCent account grant controlled access to other people. Users help answer questions such as: - Who should be able to log in to this RevCent account? - Should this person be an Administrator, Supervisor, or Employee? - Should this person be limited to one Organization? - Which Campaign-related data should this person be able to see? - Which actions should this person be allowed to perform? - Should this person be able to view list pages, or only find and open individual records? - Should this person be able to create or modify Employee accounts? - What activity has this person performed inside the web app? Users should be treated as an access-control feature, not just a contact record. --- ## User Types RevCent user access is based heavily on user type. | User Type | Organization Required? | General Meaning | |---|---:|---| | Account Owner | No | The primary owner of the main RevCent account with full account control. | | Administrator | No | A high-level sub-account with broad access to account functionality, except certain account-management actions. | | Supervisor | Yes | A lower-level management user assigned to one or more Organizations, with configurable abilities and permissions. | | Employee | Yes | A lower-level staff user assigned to one or more Organizations, with configurable permissions. | Account Owner and Administrator users are not assigned to Organizations. Supervisor and Employee users must be assigned to one or more Organizations. --- ## Relationship to Organizations Organizations are the primary grouping and visibility structure for Supervisor and Employee users. A User can be assigned to one or more Organizations when the user type requires it. The Organization then helps determine what that User can see inside the account. Conceptually: ```text Organization ↓ Associated Campaigns and other visibility associations ↓ Supervisor / Employee Users assigned to the Organization ↓ Those Users see and act within the configured boundary ``` This is why Users and Organizations should be planned together. Creating a Supervisor or Employee without the right Organization structure can lead to either too much access or not enough access. --- ## Visibility Restrictions User visibility is shaped by a combination of user type, Organization assignment, Organization associations, abilities, and permissions. The most important visibility boundary is usually Campaign association on the Organization. When a Supervisor or Employee belongs to an Organization that has selected Campaigns, the User can be restricted to Sales, Customers, and related records for those Campaigns. Conceptually: ```text User belongs to Organization ↓ Organization has Campaign association ↓ User visibility is limited to records related to those Campaigns ``` This is the primary model for restricting staff access by business, brand, store, sales flow, or operating unit. --- ## Campaign-Based Visibility Campaigns are the main way Organization-based visibility is applied to commerce records. When an Organization has Campaigns selected, Users in that Organization may only see records connected to those Campaigns, such as: ```text Sales Customers Transactions Subscriptions Trials Shipping records Chargebacks Fraud detections Other Campaign-related commerce records ``` This is especially important for multi-brand or multi-store RevCent accounts. Example: ```text Organization: Brand A Support Team Campaign association: Brand A Campaign Users: Brand A supervisors and employees Result: Users work inside the Brand A visibility boundary ``` Do not assign Campaigns to an Organization casually. Campaign association can change what Supervisor and Employee users can see. --- ## Permissions vs Visibility Visibility and permissions are different. Visibility controls which records a User can see. Permissions control what actions a User can perform. Conceptually: ```text Organization and Campaign associations = what the User can see Permissions = what the User can do Abilities = broader behavior switches for certain User types ``` A User might be able to see a record but not have permission to perform a certain action on it. A User might also have permission for an action, but still only within the records they are allowed to access through their Organization and Campaign visibility boundary. --- ## Abilities Abilities are higher-level controls that apply to Supervisor and Employee users. Common ability concepts include: | Ability | Meaning | |---|---| | View List Pages | Allows the User to view list pages, such as all sales or all customers. If disabled, the User may need to search for individual records and open detail pages directly. | | Create Employee Accounts | Allows a Supervisor to create Employee accounts inside their Organization, when enabled. | | Modify Employee Accounts | Allows a Supervisor to modify Employee accounts inside their Organization, when enabled. This can include sensitive changes such as passwords or deleting Employee accounts. | | Google AdWords Access | Allows applicable users to view Google AdWords-related data when enabled. | Abilities should be configured carefully because they affect how broadly a User can operate inside the web app. --- ## Permissions Permissions define the specific action types a Supervisor or Employee can perform. Permissions are configured by type and method. Examples include retrieve, create, edit, delete, refund, estimate, process, void, renew, expire, extend, shorten, upload, and similar action methods depending on the RevCent feature or record type. Examples of permission-controlled areas can include: ```text Campaigns Sales Customers Customer Cards Transactions Subscriptions Trials Shipping Fraud Detections Coupons Products Notes SMTP Messages Salvage Transactions ``` The exact permissions should be chosen based on the User's job. Best practice: ```text Give each User the minimum permissions needed for their role. ``` Avoid giving broad permissions just because the User is trusted. The point of sub-user accounts is to create controlled, auditable, role-specific access. --- ## Administrators Administrators are high-level sub-accounts. An Administrator can generally perform core account functionality, but is still not the same thing as the Account Owner. Administrators are not assigned to Organizations. Use Administrators for trusted account operators who need broad access across the account, not for staff who should only see one brand, team, store, or Campaign. If a person needs limited visibility, use a Supervisor or Employee assigned to an Organization instead. --- ## Supervisors Supervisors are lower-level management users. A Supervisor must be assigned to one or more Organizations. The Supervisor's access is shaped by: ```text Organization assignment Organization Campaign associations Configured abilities Configured permissions ``` A Supervisor may be allowed to create or modify Employee users within their Organization, depending on the Supervisor's abilities. Supervisors are useful for team leads, support managers, fulfillment managers, risk reviewers, or brand operators who need more capability than Employees but should not have full account-level access. --- ## Employees Employees are lower-level staff users. An Employee must be assigned to one or more Organizations. The Employee's access is shaped by: ```text Organization assignment Organization Campaign associations Configured permissions ``` Employees are intended for role-specific access. Examples: ```text Support staff who can retrieve customer and sale details. Fulfillment staff who can view shipping-related records. Risk staff who can review fraud detections or chargebacks. Customer service staff who can create notes. ``` Employees should generally receive only the permissions needed for their daily work. --- ## User Details When creating or editing a User, the business configures basic account details such as: ```text Username Password Email First name Last name Status User type Organization, when required ``` The email and username should be unique and should identify the actual person using the account. Avoid shared generic User accounts when possible. Individual accounts make activity review and accountability much clearer. --- ## User Activity RevCent can show activity for a specific User inside the web app. User activity can include page visits, searches, actions, and notes. This helps the account owner or administrator understand what a User has done during a given time period. Activity review is useful for: ```text Auditing staff actions Investigating support issues Reviewing access patterns Confirming whether a User handled a task Monitoring operational accountability ``` Because Users are access-control records, activity history is part of the value of using individual sub-accounts instead of shared logins. --- ## Customer Notes Users can create customer notes and notes on customer-related entities. For example, when viewing a Sale details page, a User can create a note for that Sale that is also attached to the related Customer. This lets RevCent show customer context across multiple customer-related detail pages. Customer notes are useful for: ```text Support history Follow-up instructions Refund or shipment context Customer service records Internal team coordination ``` Note access and creation should still respect the User's permissions and visibility boundaries. --- ## Users vs Organizations Users and Organizations are related but not the same thing. | Concept | Meaning | |---|---| | User | The sub-account that logs in and performs actions. | | Organization | The grouping and visibility boundary assigned to Supervisor and Employee users. | | Campaign | The primary commerce-data association used to restrict Organization visibility. | | Permissions | The action-level rules controlling what the User can do. | | Abilities | Higher-level controls affecting User behavior and management capability. | A User is the actor. An Organization is the boundary. A Campaign is the main commerce-data filter for that boundary. Permissions and abilities determine what the actor can do inside that boundary. --- ## Safe Access Planning When setting up Users, use a least-access approach. Recommended planning flow: ```text 1. Identify the person's job role. 2. Decide whether the person needs full-account access or limited access. 3. Use Administrator only for broad trusted account operators. 4. Use Supervisor or Employee for Organization-bound access. 5. Create or identify the correct Organization. 6. Confirm the Organization's Campaign associations. 7. Assign the User to the Organization if required. 8. Enable only the abilities and permissions needed for the role. 9. Review activity after the User begins working. ``` This helps prevent accidental overexposure of account data. --- ## Common Use Cases ### Brand-Specific Support Team A business has multiple brands in one RevCent account and wants support staff for Brand A to only see Brand A records. Recommended structure: ```text Campaign: Brand A Campaign Organization: Brand A Support Team Users: Brand A support Employees and Supervisors Visibility: Organization associated with Brand A Campaign ``` ### Fulfillment Staff A business wants warehouse or fulfillment staff to view only shipping-related information for a specific business unit. Recommended structure: ```text Organization assigned to the relevant Campaign Employee users assigned to the Organization Permissions limited to retrieve or update shipping-related records, as appropriate ``` ### Supervisor Managing Employees A business wants a team lead to manage Employee users within a specific Organization. Recommended structure: ```text User type: Supervisor Organization: assigned to the relevant team Organization Abilities: create/modify Employee accounts only if appropriate Permissions: limited to the Supervisor's operational role ``` ### High-Level Account Operator A trusted operator needs broad account access across the RevCent account. Recommended structure: ```text User type: Administrator Organization: not assigned Permissions: broad administrative capabilities, subject to Administrator limitations ``` --- ## Common Mistakes Do not: - Treat Users as customers. - Use one shared login for multiple staff members when individual accountability matters. - Make every staff member an Administrator. - Assign Supervisor or Employee users without understanding the Organization they belong to. - Forget that Campaign associations on an Organization can restrict what Users can see. - Give broad permissions when a User only needs narrow operational access. - Enable Supervisor employee-management abilities casually. - Disable list pages without realizing the User may need to search for individual records. - Assume Third Party Shop visibility is the same as Campaign-based Sales and Customer visibility. - Use Users as a replacement for customer-facing portal access. --- ## Relationship Summary Users are the people or staff accounts that operate inside RevCent. Organizations group Supervisor and Employee users and define their visibility boundaries. Campaign association is the primary way an Organization restricts sales/customer-related visibility. Permissions and abilities determine what each User can do once they are inside the account. Simple model: ```text User = sub-account Organization = access boundary Campaign = primary visibility filter Permissions = allowed actions Abilities = high-level behavior controls ``` --- ## Summary Users are web-app-only configurable sub-accounts related to the main RevCent account. They allow a business to give staff access without giving every person full account-owner control. The most important concepts are: ```text Users are sub-accounts, not customers. Users are configured in the RevCent web app. User type determines the broad access model. Administrators are broad-access sub-users and are not assigned to Organizations. Supervisors and Employees must be assigned to Organizations. Organization Campaign associations are the primary visibility restriction for Sales, Customers, and related records. Permissions control what actions the User can perform. Abilities control broader behavior for Supervisor and Employee users. User activity can be reviewed for operational accountability. ``` Used carefully, Users let a RevCent account support multiple teams, brands, stores, and operational roles while maintaining clearer access boundaries and accountability. --- Document Parent Directory * [Features](https://revcent.com/documentation/markdown/ecosystem/feature/index.md) - Non-technical markdown documentation for features within the RevCent ecosystem. A feature is a part of the RevCent ecosystem that a user can create and configure.