👥 Primary Audience: Admins , Partner Admins, Office Admins Operation Managers , Dispatchers, Accounting Staff, Safety Managers, Data Entry
This article addresses two (2) distinct permission categories that collectively constitute the administrative and data sensitivity framework of the TMS, specifically Privacy and Management permissions. These categories are consolidated within a single article as they share a foundational theme, namely the governance of company resources such as users, carriers, assets, and integrations, alongside the regulation of access to sensitive personal data including Tax Identification Numbers and Social Security Numbers.
Where to Manage Management & Privacy Permissions
⚠️ To modify these permissions, the logged-in user, preferably an administrator, must possess the “Set Permission” permission located within the Management category. Without “Set Permission”, a user can view the user profile or form but cannot adjust any permissions. For additional information regarding the “Set Permission”, please refer to the Management & Privacy Permissions article.
Management & Privacy Permissions are configured at the individual user level within the User Management interface. To adjust these settings:
Select your username located in the bottom left corner.
Navigate to the Company Profile and select the Users tab.
Choose an existing user to Edit or select the Add User button to create a new profile.
Scroll to the Permissions section and locate the Management category.
Identify the sixteen (16) individual checkboxes corresponding to the Management permissions detailed in this article:
Add User,Set Permission,Delete User,Activate Carrier,Edit Carrier,Delete Carrier,Edit Asset,Delete Asset,View Drivers,View Trucks,View Trailers,View Maintenance Records & Totals,View Accidents,View Claims,View Roadside Inspections,Edit Webhooks
Identify the three (3) individual checkbox corresponding to the Privacy permissions detailed in this article:
View Tax ID/SSN,Edit Tax ID/SSNandView PII
Privacy Permissions Breakdown
View Tax ID/SSN
The View Tax ID/SSN permission controls whether a user can see Tax Identification Numbers (TINs) or Social Security Numbers (SSNs) stored on carrier and driver records within the system. Without this permission, these fields are hidden entirely. Tax IDs and SSNs are personally identifiable information (PII) protected by privacy regulations and company policy. In trucking, carriers and owner-operators provide their Tax IDs for 1099 reporting and settlement purposes. Exposing this data broadly creates privacy and security risks including identity theft potential. This permission ensures that only staff who need Tax IDs for legitimate business purposes (such as accounting and compliance) can access them.
[Heading 4 not supported]
[Heading 4 not supported]
The carrier list grid conditionally incorporates the Tax Identification Number and Tax Identification Number Type columns contingent upon whether the active user possesses the View Tax Identification Number permission. Should a user lack this specific authorization, these columns are omitted from the carrier table entirely.
The Tax Identification Number is also displayed on the carrier profile within the Form 1099 section for users who possess this specific permission. In the event that a user lacks this authorization, both the Tax Identification Number type and the associated number remain concealed from view.
[Heading 4 not supported]
The driver list grid conditionally incorporates the Tax Identification Number column contingent upon whether the active user possesses the View Tax Identification Number permission. Should a user lack this specific authorization, this column is omitted from the driver list table in its entirety.
The Tax Identification Number is also displayed on the driver profile within the tax information section for users who possess this specific permission. Should a user lack this authorization, the tax category, identification type, and Tax Identification Number are concealed from view.
By default, this permission is assigned to the Partner Admin, Admin, and Operation Manager roles. Conversely, this permission is not granted by default to the Dispatcher, Biller, Sales Agent, Data Entry, Office Admin, Safety, or Driver roles.
✅ Best Practice: Grant this permission only to accounting, compliance, and finance staff who handle tax reporting. Do not grant it to operational roles (dispatchers, drivers, safety etc.) unless there is a specific, documented need.
Edit Tax ID/SSN
The Edit Tax ID/SSN permission controls whether a user can modify Tax Identification Numbers and Social Security Numbers stored on carrier and driver records within the system. Without it, the fields are read-only (assuming the user has View Tax ID/SSN) or hidden entirely (if they lack both permissions). Editing Tax IDs carries even higher risk than viewing them. An incorrect Tax ID results in incorrect 1099 reporting, potential IRS penalties, and compliance failures. A maliciously changed Tax ID could redirect tax reporting to the wrong entity. This permission ensures that only authorized staff can modify this critical data, and the backend policy provides server-side enforcement as an additional safeguard.
Driver Profile
Carrier Profile
By default, this permission is granted to the Support, Partner Admin, Admin, and Operation Manager roles. Conversely, it is not assigned by default to the Dispatcher, Biller, Sales Agent, Data Entry, Office Admin, Safety, or Driver roles.
✅ Best Practice: Grant Edit Tax ID/SSN to the smallest number of users possible, typically only senior accounting or compliance staff. Always pair with View Tax ID/SSN to see the data you are editing.
View PII
The View PII permission controls whether personally identifiable information (PII) is shown or masked within Alvys Insights responses. Unlike standard permissions that manage access to specific modules or actions, View PII specifically governs the visibility of sensitive data fields within the AI powered chat. It’s purpose is to ensure that data directly identifying individuals is never surfaced to unauthorized users, even if they have access to the broader data category. A user without this permission will see the Insights interface exactly like any other user, including the same results tables and input fields but sensitive values will be replaced by masked placeholders.
The Two Tier Access Model
To protect privacy, Alvys utilizes a dual requirement structure. A user must pass both security tiers for PII fields to be unmasked:
Tier 1 (Standard Data Access) : Requires at least one matching domain permission such as Billing, View Drivers, or Dispatch. This controls access to operational data fields like financial amounts, vehicle information, and trip counts.
Tier 2 (Personally Identifiable Information) : Requires both a relevant domain permission and the View PII permission. This controls the visibility of specific fields such as names, email addresses, phone numbers, dates of birth, driver license numbers, geolocation, and insurance details. Without the View PII permission, Tier 2 fields remain masked regardless of your Tier 1 domain permissions.
⚠️ The View PII permission is specifically designed for the Insights feature. A user must first have access to the Insights interface via the View Insights permission and the active tenant feature flag for this masking logic to apply.
💡 View PII alone is not sufficient to reveal data. It must be combined with the relevant domain permission for the category being queried. For example, to see a driver’s phone number, a user needs both the View PII permission and a permission from the Drivers category such as View Drivers.
Admin and Partner Admin roles receive this permission by default. All other users, such as dispatchers or sales agents, must have it explicitly granted by an administrator.
Management Permissions Breakdown
Add User
The Add User permission controls whether a user can create new user accounts in Alvys TMS. This is a foundational administrative permission that governs user provisioning ,the first step in granting anyone access to the system. Without it, the "Add User" page is inaccessible.
When this permission is active, the user can:
Navigate to the Management Page and access the Users list
Click the “Add User” button to open the new user creation form
Enter the new user's name, email address, and assign their initial role
Set or leave the initial permission set, which is further discussed in the Set Permission section of this article.
Send the invitation or account activation to the new user
User account creation is a sensitive operation because new accounts must be correctly configured with appropriate roles and permissions from their inception. Misconfigured permissions can result in users having excessive access to sensitive data, while overly restrictive initial configurations can impede productivity. The Add User permission is therefore typically limited to a small number of administrative roles with the maturity and training to properly configure new accounts.
⚠️ The Add User permission is tightly coupled with the Set Permission authorization through a dual requirement. This configuration necessitates the possession of both the Add User and Set Permission authorizations to access the permission assignment step.
A user with Add User but without Set Permissions can initiate user creation but cannot assign permissions to newly created users, resulting in an incomplete account setup. Conversely, a user with Set Permissions but without Add User cannot navigate to the user creation workflow at all, even though they could theoretically assign permissions to existing users.
By default, this authorization is granted to the Support, Partner Admin, Admin, Operation Manager, and Office Admin roles. Conversely, this permission is not assigned by default to the Dispatcher, Biller, Sales Agent, Data Entry, Safety, or Driver roles. The primary target audience for this functionality comprises Office Administrators, Human Resources Administrators, and Operations Managers who are tasked with the onboarding of new employees and the systematic management of user accounts.
✅ Best Practice: Grant Add User only to administrative roles responsible for employee onboarding. Do not assign it broadly just for convenience, it is better to have one or two trusted people who handle account creation consistently. Always pair with Set Permission so the same person can both create the account and configure its permissions.
Set Permission
The “Set Permission” permission controls whether a user can modify the permissions assigned to other users from the user profile. Without it, the permissions section on the user detail page is read only the user can view but not modify another user's permissions. This is one of the most sensitive administrative permissions in the system as it determines who can change what other users are authorized to do. This makes “Set Permission” one of the highest-privilege capabilities in Alvys. It should be restricted to highly trusted administrators who understand the implications of each permission.
When this permission is active, the user can:
Navigate to the Management page then click on Users.
Locate the specific user you wish to modify and click on their profile to open it.
Scroll to the permissions section to view the full list of enabled and disabled permissions for that user.
Toggle individual permissions on or off
By default, this authorization is extended to the Support, Partner Admin, Admin, Operation Manager, and Office Admin roles. Conversely, this permission is not assigned by default to the Dispatcher, Biller, Sales Agent, Data Entry, Safety, or Driver roles.
✅ Best Practice: The Set Permission authorization should be restricted exclusively to administrators who maintain formal responsibility for user access management. Furthermore, permission modifications should be audited on a regular basis to identify any unauthorized adjustments.
Activate Carrier
The Activate Carrier permission ensures that only authorized staff can change a carrier’s status e.g. from inactive or pending to active. Carrier activation typically follows carrier onboarding and compliance review, including insurance verification, authority checks, and documentation review. When a company establishes a new carrier relationship, the carrier must be activated before loads can be assigned. Conversely, when a carrier relationship ends or a carrier has compliance issues, deactivation prevents further assignments.
⚠️ The Edit Carrier permission must be paired with this permission in order to modify the carrier status
The Activate button or status toggle appears on carrier records for users with this permission. Without it, the user can view carrier records but cannot change their status.
Navigate to the carrier list and open a pending or inactive carrier record.
Click on the carrier status field.
Select the relevant status (e.g., Active) to activate the carrier.
The carrier becomes available for dispatch use immediately upon activation.
By default, this permission is extended to the Partner Admin, Admin, Operation Manager, Dispatcher, Biller, Sales Agent, Data Entry, and Office Admin roles. Conversely, this permission is not assigned by default to the Safety or Driver roles.
✅ Best Practice: Assign Activate Carrier only to compliance staff or operations managers who are part of the carrier onboarding workflow. Pair this with a documented checklist: insurance certificate on file, operating authority verified, contact information complete before any activation is approved.
Edit Carrier
Carrier records need to stay current. Insurance policies expire and are renewed, contacts change, and addresses change. Without the ability to edit carrier records, outdated information remains in the system and can cause dispatch errors, compliance gaps, or failed communications. The Edit Carrier permission controls whether a user can modify carrier profile information, such as contact details, addresses, payment terms, insurance information, MC and DOT numbers, and other carrier attributes. Without it, carrier data is read-only. Accurate carrier data is essential for load assignment, settlement, and regulatory compliance.
⚠️ This Permission does not grant the ability to activate or delete a carrier, those require separate permissions.
The Edit Carrier permission ensures that only authorized staff can modify this data, preventing unauthorized changes that could affect payments, compliance status, or operational communications.
By default, this authorization is extended to the Support, Partner Admin, Admin, Operation Manager, Dispatcher, Biller, Sales Agent, Data Entry, and Office Admin roles. Conversely, this permission is not assigned by default to the Safety or Driver roles.
✅ Best Practice: Grant the Edit Carrier permission to all operational roles that work with carriers. This broad default assignment reflects the routine nature of carrier data maintenance.
Delete Carrier
Carrier records may need to be deleted when carriers go out of business, when duplicate records are created by mistake, or when a carrier relationship is permanently terminated. Without the ability to delete records, your carrier list can accumulate stale or duplicate entries that create confusion during dispatch. The Delete Carrier permission controls whether a user can permanently delete carrier records from the system. Carrier records contain historical load, payment, and compliance data; deleting a carrier removes this audit trail. This permission does not require Edit Carrier or Activate Carrier.
In almost all cases, deactivating a carrier (using Activate Carrier) is the appropriate action rather than deleting it. The Delete Carrier permission is restricted to the highest-level administrators and should be used only as a last resort.
By default, this authorization is extended exclusively to the Support and Partner Admin roles. Conversely, this permission is not assigned by default to the Admin, Operation Manager, Dispatcher, Biller, Sales Agent, Data Entry, Office Admin, Safety, or Driver roles. Given its administrative significance, this specific action should be performed rarely and must remain subject to rigorous organizational controls.
✅ Best Practice: Never grant Delete Carrier to non-admin roles. Even for Partner Admins, consider whether deactivation would serve the same purpose. Require verbal confirmation before performing carrier deletions.
Delete User
The Delete User permission controls whether a user can permanently delete other user accounts from the system. Like Delete Carrier, this is a destructive action that removes user records permanently. When an employee leaves the company, their Alvys account should be deactivated or removed, and Delete User is the permission that allows this action. However, because user deletion is irreversible and can affect audit trails, it must be handled carefully. In most cases, disabling a user account is preferable to deletion. This permission is restricted to the highest-level administrators.
By default, this authorization is extended exclusively to the Support and Partner Admin roles. Conversely, this permission is not assigned by default to the Admin, Operation Manager, Dispatcher, Biller, Sales Agent, Data Entry, Office Admin, Safety, or Driver roles.
✅ Best Practice: Disable user accounts instead of deleting them. This preserves the audit trail and prevents data loss. To disable a user account, navigate to the company profile, select the Users tab, search for the user, click the status dropdown for that user, and select the Disabled option. Reserve deletion for duplicate user accounts or test user accounts with no meaningful history.
Edit Asset
The Edit Asset permission controls whether a user can modify asset records, including drivers, trucks, and trailers. This is a broad permission that governs the ability to update asset profiles, change asset information, and manage asset-related data such as driver rate policies and bank information.
Asset records form the operational foundation. Driver qualifications, truck specifications, trailer types, and equipment availability all depend on accurate asset data. Additionally, driver rate policies and bank information are sensitive financial data that affect driver settlements. This permission ensures that only authorized staff can modify asset records, preventing unauthorized changes that could impact operations, settlements, or compliance.
When this permission is active, the user can:
Create and import asset records, such as drivers, trucks, and trailers.
Open any asset record (driver, truck, or trailer) and edit fields such as subsidiary, email, make, model, year, VIN, license plate, and more.
By default, this authorization is extended to the Partner Admin, Admin, Operation Manager, Biller, Data Entry, Office Admin, and Safety roles. Conversely, this permission is not assigned by default to the Dispatcher, Sales Agent, or Driver roles. Notably, Dispatchers and Sales Agents do not receive the Edit Asset authorization by default, despite their ability to view asset data. This functional separation ensures that dispatch personnel can view driver, truck, and trailer information for assignment purposes without maintaining the capacity to modify existing records.
✅ Best Practice: Grant the Edit Asset permission to Billers and Data Entry staff who manage asset onboarding and maintenance. Consider whether Dispatchers need Edit Asset access; in many companies, dispatchers should be able to view but not modify asset records.
Delete Asset
The Delete Asset permission controls whether a user can delete asset records (drivers, trucks, trailers) from the system. This is a destructive action that removes the asset and its associated data. In most cases, deactivating an asset is the appropriate action.
By default, this authorization is extended exclusively to the Support and Partner Admin roles. Conversely, this permission is not assigned by default to the Admin, Operation Manager, Dispatcher, Biller, Sales Agent, Data Entry, Office Admin, Safety, or Driver roles.
✅ Best Practice: The Delete Asset permission should never be granted to non administrative roles. As a matter of best practice, the deactivation of assets should be utilized rather than deletion for assets that are no longer in service.
View Drivers
The View Drivers permission controls whether a user can see the driver list and individual driver profiles. Without it, the user cannot select the Driver option from the Assets menu.
Driver records are referenced throughout the system in load assignments, dispatch planning, settlement records, and safety reports. Most operational roles need at least read access to driver data to perform their functions effectively.
By default, this permission is granted to all roles except the Driver role.
✅ Best Practice: Grant the View Drivers permission to all operational staff. The Driver role should be excluded, as drivers do not use the TMS web interface and primarily interact with the system through the Alvys mobile app.
View Trucks
The View Trucks permission allows a user to see truck records. Without it, the truck list is hidden and a user cannot view any truck profiles. Its default role assignments, behavior, and risk profile are identical to View Drivers.
Truck records contain equipment specifications, maintenance status, and availability data. Dispatchers need truck visibility for load assignment; billers need it for settlement context; safety staff need it for compliance monitoring.
✅ Best Practice: Assign View Trucks to all dispatchers, fleet managers, and operations managers. Pair with the View Drivers permission for anyone who needs to use Assignment Preferences. The Driver role should be excluded, as drivers do not use the TMS web interface and primarily interact with the system through the mobile app.
View Trailers
Allows a user to see the list of trailers in the Assets section of Alvys and open individual trailer records. Its default role assignments, behavior, and risk profile are identical to View Drivers and View Trucks. Without this permission, the trailer menu item and list are hidden. It is broadly assigned to almost all roles, as Dispatchers need trailer visibility for load planning, and safety staff need it for inspection and maintenance monitoring.
✅ Best Practice: Grant View Trailers alongside Truck and Drivers View permissions as a set.
View Maintenance Records & Totals
This permission determines whether authenticated users can access the maintenance module, view maintenance records, add maintenance records, review closed maintenance records etc., and also see maintenance totals for assets (Trucks and trailers). Without it, maintenance data is hidden.
💡 View Maintenance Amounts is an additional permission that reveals the dollar amounts within maintenance records. Both permissions must be active for a user to see the full financial details of maintenance work. With View Maintenance Amounts, dollar amounts on maintenance records, including parts costs, labor costs, and totals, become visible. Without this permission, those fields are hidden.
By default, this specific authorization is extended to the Support, Partner Admin, Admin, Operation Manager, Dispatcher, Office Admin, and Safety roles. Conversely, this permission is not assigned by default to the Biller, Sales Agent, Data Entry, or Driver roles.
This data is essential for fleet managers and safety staff to ensure vehicles meet DOT requirements and are safe to operate. The narrower default assignment (compared to Asset View permissions) reflects the specialized nature of maintenance data , dispatchers need it for equipment decisions, but billers and sales agents typically do not.
✅ Best Practice: Grant this permission to all fleet managers, maintenance coordinators, and anyone responsible for scheduling repairs. Grant View Maintenance Amounts only to controllers, owners, and operations managers who need to track maintenance costs. Also include these permissions as part of the full Safety View permissions set, since users who need maintenance data typically also require access to accident, claim, and inspection records.
View Accidents
The View Accidents permission enables a user to access the Accidents page within the Safety menu and observe detailed accident reports. The View Accidents permission controls whether a user can see, add, and edit accident records associated with assets, including accident reports, dates, descriptions, and related details. When this permission is active, the Safety Accidents menu option becomes visible and accessible. Conversely, in the absence of this permission, any attempt to navigate to the Accidents page is blocked.
This permission is part of the Safety View permissions set. Accident records contain sensitive safety and legal information and may be involved in insurance claims, legal proceedings, and regulatory investigations. Access should be limited to safety staff, dispatchers who need to consider safety history when making assignments, and management.
By default, this specific authorization is extended to the Support, Partner Admin, Admin, Operation Manager, Dispatcher, Office Admin, and Safety roles. Conversely, this permission is not assigned by default to the Biller, Sales Agent, Data Entry, or Driver roles.
✅ Best Practice: Grant as part of the full Safety View permissions set.
View Claims
The View Claims permission controls whether a user can access the Claims report page within the Safety menu to view, modify, and add insurance and cargo claim records associated with specific assets. This includes claim amounts, statuses, descriptions, and related details. Without it, claims data is hidden. Furthermore, insurance claims incorporate sensitive financial and legal information derived from incidents involving organizational assets. Consequently, access should be restricted to safety personnel, management, and operational roles that require comprehensive visibility into claim histories to facilitate informed risk management and assignment decisions.
By default, this permission is granted to the Support, Partner Admin, Admin, Operation Manager, Dispatcher, Office Admin, and Safety roles. Conversely, this permission is not assigned by default to the Biller, Sales Agent, Data Entry, or Driver roles.
✅ Best Practice: Assign the View Claims permission to owners, controllers, safety managers, and compliance staff. Do not assign it broadly, as claims data can have legal implications and should be accessed only by staff actively involved in claims management.
View Roadside Inspections
The View Roadside Inspections permission allows a user to access the Roadside Inspections page within the Safety menu to view, add, and edit roadside inspection records for assets . This includes inspection results, violations, dates, and locations. Roadside inspection records are critical compliance data, directly impacting the company’s DOT safety rating (CSA scores) and potentially influencing insurance premiums and regulatory oversight. Safety staff use this information to identify problematic vehicles or drivers, while dispatchers may consider inspection history when making assignment decisions.
By default, this authorization is extended to the Support, Partner Admin, Admin, Operation Manager, Dispatcher, Office Admin, and Safety roles. Conversely, this permission is not assigned by default to the Biller, Sales Agent, Data Entry, or Driver roles.
✅ Best Practice: Assign the View Roadside Inspections permission to safety managers, compliance officers, and operations managers who actively monitor CSA scores. This is a foundational safety permission for anyone responsible for DOT compliance. Include this permission as part of the full Safety View permissions set.
Edit Webhooks
Webhooks are automated connections that send data from Alvys to external software systems, such as load status changes, new bookings, or settlement events. The Edit Webhooks permission controls whether a user can create, update, delete, and enable or disable webhook integrations within the company’s subsidiary settings. Without this permission, the webhooks section of company settings is inaccessible. This is a technical permission typically needed only by IT administrators or integration engineers. Misconfigured webhooks can send sensitive data to unauthorized endpoints, cause integration failures, or overwhelm external systems with excessive notifications.
When this permission is active and the user holds the required role, the user can:
View the list of configured webhooks per subsidiary.
Add a new webhook endpoints
Edit existing webhooks (URL, events, authentication)
Delete webhooks
Granted by default to: Support, Partner Admin, Admin, Operation Manager. Not granted by default to: Dispatcher, Biller, Sales Agent, Data Entry, Office Admin, Safety, Driver. No non-admin role receives this permission by default.
✅ Best Practice: Assign Edit Webhooks only to technical administrators or IT staff who understand what each webhook does and where it sends data. Before editing or deleting any webhook, confirm with the person or team who built the integration what the downstream impact will be. Do not grant this permission to operational roles.
Frequently Asked Questions (FAQs)
Q: Should I grant View Tax ID/SSN and Edit Tax ID/SSN together? A: Not necessarily, as they are independent permissions. You can grant View Tax ID/SSN to staff who only need to view the data without the power to change it; however, if you grant Edit Tax ID/SSN, you should always pair it with View Tax ID/SSN so the user can actually see the data they are modifying.
Q: Who has access to sensitive personal information (PII) by default? A: To maintain strict security, the View PII permission is granted by default only to Admin and Partner Admin roles, while all other users must have it explicitly assigned by an administrator.
Q: If I have the View PII permission, can I see all personal data in the system? A: No, you must hold both the View PII permission and the relevant domain permission such as Billing, Dispatch, View Trucks, or View Drivers to reveal sensitive details in your results.
Q: I was just granted the View PII permission, but I still see the data being masked. How do I fix this? A: Permission updates do not apply to active sessions, so you must log out and log back in to refresh your access and view unmasked data.
Q: What happens if my View PII permission is revoked while I am currently using Insights? A: Your current session will retain its access level until you log out; a fresh login is required to apply the updated, restricted security settings.
Q: What specific fields are protected by the View PII permission? A: This permission masks highly sensitive details including names, contact information, dates of birth, license numbers, insurance details, and geolocation.
Q: What is the difference between the Edit Carrier and Activate Carrier permissions? A: Edit Carrier allows a user to modify profile data like contact information and payment terms. Activate Carrier specifically controls the ability to change a carrier's status, such as moving them from pending to active.
Q: Why are Dispatchers denied the Edit Asset permission by default? A: While dispatchers must see assets to assign loads, editing asset records involves sensitive financial data like driver rate policies and bank information. To maintain security, these administrative tasks are reserved for billers, office admins, and data entry staff.
Q: Can I grant individual Safety View permissions instead of the entire set? A: Yes, each safety permission operates independently. However, for a consistent user experience and to ensure the Safety Report page functions correctly, it is recommended to grant all safety-related permissions as a complete set.
Q: Can a user create an account if they have the Add User permission but lack Set Permission? A: Yes, the user can initiate the creation of a new account. However, because they lack Set Permission, the permissions section will be read-only, and the new account will default to standard role settings until an administrator with set permissions adjusts them.
Q: Why is the Set Permission authorization considered a high-privilege capability? A: This permission allows a user to modify what every other person in the company is authorized to do. Because it governs the entire security framework of the system, it should be restricted to a very small number of trusted administrators.
Q: Is the Delete Carrier permission required to deactivate a carrier? A: No. Delete Carrier and Activate Carrier (deactivation) are separate. It is almost always preferable to deactivate a carrier to preserve historical load and payment data rather than deleting the record entirely.
Q: Who should be granted the Edit Webhooks permission? A: This should be restricted to IT administrators or integration engineers. Since webhooks send data to external endpoints, misconfiguration can lead to data breaches.
Q: Does the Edit Webhooks permission require any other specific authorizations? A: Edit Webhooks operates independently. However, because these settings are located within the Company Settings area, the user typically needs an admin-level role to navigate to that section of the TMS.
Next Steps
⏭️ Proceed to the General Permissions Article, which explains how to manage foundational, system-wide permissions in Alvys. This article covers permissions that affect access across multiple modules, including load board integrations, historical data editing, calendar date controls, load unlocking, and maintenance financial visibility.