Try for Free Contact Us
Key Features
  • Microsoft Azure
  • Remote Monitoring & Mangement
  • Antivirus & Antimalware Protection
  • Backup & Disaster Recovery
  • Documentation and Asset Management
  • Ticketing & Helpdesk
  • Top-Tier Security Compliance
    • One Platform
    All the Features

    Documentation

    MSPControl General Policies

    The MSPControl General Policies section defines policy-based configurations that govern session security, password enforcement, breach validation, authentication rules, and peer management for your MSPControl deployment. This page provides detailed documentation for all items listed under the “Policies > MSPControl” section in the platform.

    Table of Contents

    MSPControl Policy

    The MSPControl Policy page provides system-wide configuration parameters that influence session behavior, password rotation, peer access expiration, and breach protection mechanisms.

    MSPControl General Policies
    MSPControl Policy Page
    MSPControl 2FA Configuration

    MSPControl Settings

    Configure system-wide parameters related to session management and password breach validation.

    • Default Session Limit (minutes): Specifies how long user sessions can remain active. Restart of App Pool might be required to apply.
    • Enable Pwned Password Database Search: When enabled, passwords are checked against a known breach database to ensure security.
    • Connection String To Pwned Password Database: Defines how the system connects to the breach-checking service. This field is encrypted and hidden from view.

    Peer Account Password Policy

    Establishes rules for peer password complexity and lifecycle management.

    • Repair Settings for Organizations: Restores peer password rules to default for linked orgs.
    • Min/Max Length: Defines acceptable password length range.
    • Enforce Password History: Prevents reuse of recent passwords (by number).
    • Notification Days: Days before expiry when users receive a change notification.
    • Auto Renew Days: Passwords will auto-renew after this many days.
    • Max/Min Password Age: Forces periodic renewal and sets how soon a new password can be changed again.
    • Send Password Change Notification: Sends system alerts after successful change.

    Account Lockout & Complexity Settings

    Configure limits for reset codes, lockout behavior, and required password strength.

    • Reset Code Life Span: Minutes a reset code remains valid.
    • Enable Lockout Settings: Activates the threshold and duration settings below:
      • Account Lockout Duration: Time (in minutes) that a user is locked out.
      • Account Lockout Threshold: Number of failed attempts before lockout.
      • Reset Account Counter Lockout After: Period to clear failed attempts counter.
    • Enable Password Complexity: When checked, minimum complexity values apply:
      • MinUpperCase: At least this number of uppercase letters required.
      • MinNumbers: Minimum numeric digits.
      • MinSymbols: Minimum required special characters.
    • Invite Expired Hours: Number of hours until peer invitation becomes invalid.
    • Check Password for Exposure in Prior Breach: Rejects passwords exposed in previous breaches.
    • Breach Tolerance: Minimum accepted score from breach database (0 = fail on any exposure).

    End User Portal

    Controls two-factor authentication enforcement and preferences for user logins.

    • Require Two Factor Authentication: Forces end users to complete 2FA on login.
    • Default Two Factor Provider: Set default method (e.g., SMS).
    • Override SMS Two Form if User Has Microsoft MFA: Prioritizes MS MFA if user is already enrolled, skipping SMS fallback.

    Best Practices

    • Use pwned password checks and enforce complexity to reduce breach risks.
    • Apply lockout thresholds to prevent brute-force attacks.
    • Configure reasonable password aging and history rules for compliance.
    • Enable 2FA with a secure provider for all end users and peers.
    • Set session timeouts to limit risks of unattended sessions.

    External Login Settings

    The External Login Settings page allows administrators to configure Azure App Registrations for three key components of MSPControl: Portal, Core Portal, and WebDav Portal. These settings enable secure authentication flows using Azure AD, supporting OAuth-based sign-ins for staff and users.

     

    External Login Settings
    External Login Settings – WebDav

     

    Azure App Registrations – Portal

    • Login Enabled: Enables external login functionality for the main user portal.
    • Application (Client ID): Azure app registration ID used to identify the app.
    • Redirect URL: The callback URL used by Azure AD after successful authentication.
    • Client Secret: Secret key used to authorize the app — this is stored securely and masked.
    • Auth Context ID: The authorization context used to scope user access.

     

    Azure App Registrations – Core Portal

    • Login Enabled: Toggles Azure login for the system Core Portal interface.
    • Application (Client ID): App identifier specific to the Core Portal instance.
    • Redirect URL: Endpoint that receives the login response for core portal users.
    • Client Secret: OAuth client secret for authenticating Core Portal sessions.
    • Auth Context ID: Used to define the authentication context, same as the main portal or different per configuration.

     

    Azure App Registrations – WebDav

    • Login Enabled: Activates login flow via Azure AD for WebDav access.
    • Application (Client ID): Identifier for the WebDav application in Azure.
    • Redirect URL: Return URL specific to WebDav users after login approval.
    • Client Secret: Security credential used in WebDav authentication handshake.
    • Auth Context ID: Context ID used for validating and grouping WebDav login access.

    Best Practices

    • Use separate Azure App Registrations for each portal to maintain clear access control.
    • Keep client secrets secure and rotate them periodically.
    • Match Redirect URLs exactly with what is defined in your Azure AD App registration.
    • Use consistent Auth Context IDs if shared logic is used across portals.
    • Verify that login flows are tested after saving changes to avoid service disruption.

    Branding Policy

    The Branding Policy section allows administrators to customize the visual identity of the MSPControl environment across portals, emails, and system pages. It defines logos, themes, error pages, and address details that appear throughout the interface.

    Branding Policy Configuration Guest User Redirect Branding Settings

    Branding Policy Images

    • Logo: Main platform logo used in MSPControl UI.
    • Logo (User Portal): Specific logo used in the end-user portal interface.
    • Favicon: Icon displayed in the browser tab for all MSPControl pages.
    • Background Image: Customizable background shown in selected pages (optional).
    • Background Color: Fallback color if background image is not used.

    Brand Footer and Error Page

    • Powered By Text: Label shown in the portal footer (e.g., company name).
    • Company Link: URL the footer text links to.
    • Error File HTML Text: Custom HTML shown when system error pages are triggered (fully editable).

    Default View Mode

    • Virtuworks Mode: Toggles whether Virtuworks defaults apply to the layout.
    • Font Size: Selectable font scale for the UI (e.g., MD).
    • Theme: Theme color scheme selector (e.g., Blue).
    • Skin: UI skin styling (e.g., Dark).

    Branding Policy Address Fields

    • Company Name: Displayed as sender name in system notifications.
    • Address Line 1 / 2: Physical address displayed on system-generated communication.
    • City / State / Zipcode / Country: Legal location of the service provider.
    • Phone / Fax: Contact numbers shown where applicable (e.g., on email signatures).

    Guest Users Policy

    • Guests Redirect Page: Rich-text area for setting up an HTML-based redirect notice shown to unauthenticated or guest users.

    Best Practices

    • Use consistent logo branding between admin and user portals.
    • Customize the error HTML with helpful recovery links or branding details.
    • Ensure address and contact info matches your organization’s public records.
    • Preview view mode changes on multiple devices before rollout.
    • Leverage guest redirect logic to guide external users to proper login or info pages.

    Subscriptions Policy

    The Subscriptions Policy section manages how MSPControl handles automated billing, subscription messages, payment gateways, and tax integration. It provides system-wide parameters for enabling subscriptions, configuring cancellation notes, integrating Authorize.Net, and managing TaxJar Nexus addresses.

    Subscriptions Policy Subscriptions Policy Subscriptions Policy

    Settings

    • Subscriptions Enabled: Globally enables or disables subscription management in MSPControl.

     

    Subscriptions Settings

    • Cancellation Note: Custom text sent to customers when a subscription is cancelled.
    • Invoice Message: Additional text appended to invoices (e.g., terms & conditions notice).
    • Subscriptions Immediate Cancel Allowed: If enabled, allows immediate cancellation of subscriptions.

     

    Authorize Settings

    • Enabled: Enables Authorize.Net as a payment provider.
    • Allow Import of Existing CIM Profile: Lets the system import saved customer profiles from Authorize.Net.
    • Environment in use: Allows selection between Production and Sandbox environments.

     

    Production Settings / Sandbox Settings
    • API Login Id: Login credential for Authorize.Net environment.
    • API Transaction Key: Transaction key required to authenticate with Authorize.Net.
    • Test Settings: Verifies connection between MSPControl and the gateway.

     

    Suspension Rules

    • Number of Days Overdue before Suspension: Defines delay before suspending a subscription after missed payment.
    • Number Of Days Exceeding the Credit Limit before Suspend: Triggers suspension after credit threshold is breached for this duration.

     

    Accepted Payment Types

    • Credit Card Enabled: Allows credit card transactions.
    • Bank Account Enabled: Allows direct debit (if available from provider).

     

    Wells Fargo Gateway API Settings

    • Enabled: Enables Wells Fargo API integration (if configured).

     

    TaxJar Settings

    • Enabled: Enables TaxJar for automated tax calculation.
    • API Token: Authorization token used to access the TaxJar API.

     

    Nexus Address Configuration

    • Street Address 1 / City / State / Zip: Defines legal location (nexus) for sales tax purposes.
    • Country / Region: Must be aligned with TaxJar-supported regions.
    • Test Settings: Validates current address configuration and token validity.
    • Table View: Lists all added Nexus addresses with ability to edit/delete.

    Best Practices

    • Use the production environment only after validating API keys in sandbox.
    • Define realistic overdue periods to allow billing retries before suspension.
    • Customize messages to reflect your billing and cancellation policies.
    • Use Nexus address lists in every region where sales tax collection is required.
    • Enable only supported payment methods configured with your payment processor.

    Product Categories

    The Product Categories section defines the structure of your subscription marketplace. It controls how products are grouped and presented to customers, both visually and logically. Each category helps organize commercial offerings into a hierarchical catalog of services, simplifying navigation for users and streamlining backend automation.

    These categories are tightly integrated with the Subscriptions Policy. When customers purchase a product from a category, MSPControl can automatically provision associated resources, apply quotas, and enable related modules. This system ensures that service delivery is directly aligned with sales logic.

    Product Categories

    Category Creation Fields

    • Name: Title of the product category. Appears in storefronts and selection lists.
    • Description: Optional field used for explanatory text or internal notes.
    • Image: Icon or visual element used to represent the category in user interfaces (optional).
    • Parent: Allows nesting under broader categories for better marketplace structure.

    Product Categories

    Use Cases & Hierarchies

    • Use top-level categories like “Microsoft Online Services” or “VirtuWorks Hosted Services” to group related cloud offerings.
    • Subcategories such as “Office 365,” “Azure,” or “Cloud Folders” can then be attached under these umbrella groups.
    • Custom vertical offerings (e.g., “Virtual Office,” “Endpoint Security”) can be defined based on business needs.

    Best Practices

    • Use concise, recognizable names to ensure a smooth user experience.
    • Structure the marketplace using parent-child nesting to simplify product browsing.
    • Add relevant images or icons to each category for easier visual recognition.
    • Always confirm that categories are correctly linked to automation logic within subscription workflows.

    Invoice Terms

    The Invoice Terms page allows administrators to define standard billing terms that determine how long customers have to pay invoices after issuance. These terms are applied to customer profiles and invoices throughout the MSPControl system.

    Invoice Terms

    Invoice Terms Table

    Each entry includes the following fields:

    • Name: Descriptive label for the term, often using industry-standard names such as NET 10, NET 30, or COD (Cash on Delivery).
    • Days: The number of calendar days after an invoice is issued before it becomes due.
    • Default: Indicates which invoice term is set as the system default for new customers.
    • Edit / Delete: Modify or remove existing invoice terms from the table.

     

    Creating a New Invoice Term

    To define a new term:

    1. Click Add New.
    2. Enter a Name (e.g., NET 45).
    3. Specify the Days field to define the payment window.
    4. Click Add New again to save the term.

    Invoice Terms

    Use Case

    Invoice terms influence payment timelines for billing and account receivables. For example, a NET 30 setting grants 30 days for payment. MSPs can define terms according to their billing policy, and optionally set one term as default for automatic assignment.

    Best Practices

    • Use descriptive and standard naming conventions like NET 15 or NET 30.
    • Assign a default term that aligns with your most common client agreement.
    • Avoid modifying terms after invoices are issued to maintain billing integrity.

    Mailchimp Policy

    The Mailchimp Policy page configures the connection between MSPControl and Mailchimp, enabling integration with mailing lists for customer communication, marketing, or system-generated notifications.

    Mailchimp Policy

     

    Mailchimp Settings

    • API Key: Secure access token that authorizes MSPControl to communicate with the Mailchimp platform. This key is stored securely and not visible.

    Members List Configuration

    Up to three different audience lists can be configured to allow customer segmentation or different messaging flows. Each entry contains:

    • Use List: Enables or disables synchronization with the specified list.
    • List ID: Unique identifier for the Mailchimp list to sync with (retrieved from Mailchimp UI).
    • List Name: Descriptive label for identifying the list within MSPControl.

    Usage Notes

    • Only enabled lists are synced with MSPControl users or tenants.
    • Administrators can target specific Mailchimp lists for onboarding emails, promotions, or client updates.

    Best Practices

    • Use a separate Mailchimp list for each client segment or communication flow.
    • Keep your API key secure and avoid sharing it across environments.
    • Ensure the List ID and List Name match exactly with your Mailchimp dashboard.
    • Periodically review which lists are active to avoid syncing outdated data.

    Check In Policy

    The Check In Policy page defines work hour tracking policies, lunch scheduling, utilization benchmarks, and notification roles for check-in events across the MSPControl platform.

    Check In Policy Check In Policy

    Check In Settings

    • Enable Check In: Activates the entire check-in tracking system for the current organization.
    • Max Hours Per Day: Defines the daily cap on recorded working hours.

    Lunch Scheduling

    • Lunch Range Start Time / End Time: Timeframe within which lunch breaks can be taken.
    • Lunch Interval: Duration allocated for a lunch break (e.g., 15 minutes).
    • Lunch Schedule Type ID: Identifier used to associate this check-in policy with a predefined lunch schedule.

    Utilization and Notifications

    • Minimum Utilization Rate (%): Target minimum percentage of scheduled hours that should be worked.
    • Check In / Out Notification Recipients: Email addresses (comma-separated) to receive notifications on check-in activity.

    Administrative Scope

    • Administrators for all users: Peer accounts selected to manage and view all check-in records across users.
    • Check-in Authorizers: Designated approvers responsible for validating or overseeing check-in compliance.

    Best Practices

    • Define realistic daily caps for total recorded hours to prevent misuse or overreporting.
    • Ensure lunch windows do not overlap with scheduled work constraints or automated rules.
    • Assign responsible administrators and authorizers for policy enforcement.
    • Use notification recipients to keep stakeholders informed about attendance and time tracking compliance.

    Customer Automatic Signup Policy

    The Customer Automatic Signup Policy enables streamlined registration for new clients through the MSPControl API. When activated, the system automatically creates a customer record and optionally associates a default hosting plan. This reduces manual onboarding and allows custom messaging during the signup process.

    Customer Automatic Signup Policy

    Settings

    • Customer Automatic Signup Enabled: Toggles the availability of the signup endpoint (/api/Customers/Create).

    Default Hosting Plan

    • Default Hosting Plan for Create Subscription: Specifies which hosting plan to assign to new customers upon signup. If no plan is selected, none will be provisioned automatically.

    Signup Form Messaging

    • Thank You Message: HTML-enabled field for the confirmation message shown after successful signup.
    • Customer Automatic Signup Title: HTML field to define the title/header displayed on the signup page.

    Best Practices

    • Keep HTML content in confirmation and title fields minimal and mobile-friendly.
    • Test your API integration thoroughly before directing customers to it.
    • Link an appropriate default hosting plan only if you want to provision services automatically.
    • Monitor API usage to detect abuse or misconfigurations in public signup forms.

    Chat Beacon Policy

    The Chat Beacon Policy integrates real-time messaging via ChatBeacon into the MSPControl interface. It allows administrators to configure visibility, survey settings, and identity variables used in the chat widget.

    Chat Beacon Policy

    Chat Beacon Settings

    • Enable Chat Beacon: Activates the ChatBeacon integration across MSPControl.
    • Integration Script Tag: JavaScript snippet required to load the chat client. Provided by ChatBeacon admin interface.
    • Skip Pre-chat Survey: Skips initial survey questions before a session begins.
    • Skip Post Chat Survey: Skips final feedback survey after a session ends.

    Chat Beacon Site Variables

    These variables are used to pass user details to ChatBeacon for agent context. Add them in the ChatBeacon Admin Console:

    • Username: accountUsername
    • Email: accountEmail
    • Full Name: accountFullName
    • Phone: accountPhone

    To use: Go to ChatBeacon Admin Console → Click Domain Name → Site Variables → Add your key (e.g., account).

    Best Practices

    • Ensure the script tag is copied exactly from your ChatBeacon instance.
    • Only skip surveys if you’re gathering feedback via another method.
    • Keep variable names consistent with the MSPControl account schema.
    • Test chat widget behavior on both client and admin portals after setup.

    Chat Beacon Policy – WebDav Portal

    The Chat Beacon Policy – WebDav Portal enables embedded ChatBeacon support on the WebDav interface in MSPControl. It allows communication via a JavaScript widget and includes survey and variable mapping options for authenticated user sessions.

    Chat Beacon Policy - WebDav Portal

    Chat Beacon Settings

    • Enable Chat Beacon: Enables ChatBeacon widget on the WebDav interface.
    • Integration Script Tag: JavaScript code that embeds the chat functionality on the portal. Provided by ChatBeacon Admin.
    • Skip Pre-Chat Survey for Authenticated Guests: Suppresses the pre-chat form if the user is already authenticated.
    • Skip Post Chat Survey: Disables the post-chat feedback prompt.

    Chat Beacon Site Variables

    These variables personalize and authenticate the chat experience based on MSPControl account information. Must be registered in the ChatBeacon Admin Console under the matching site domain.

    • Login Name: accountUsername
    • Display Name: accountFullName
    • Account Name: accountEmail

    Best Practices

    • Use dedicated script tags per portal (WebDav, main UI, Core Portal) to isolate behavior.
    • Disable surveys selectively to streamline user flow while maintaining data collection when needed.
    • Confirm ChatBeacon variables are mapped correctly in both MSPControl and the ChatBeacon Admin Console.
    • Test across authenticated and guest sessions to ensure behavior matches expectations.

    ConnectWise Integration Policy

    The ConnectWise Integration Policy section allows MSPControl administrators to configure how service tickets are automatically generated and managed using ConnectWise APIs. This includes ticket mapping for specific operational events, dashboard linking, status control, and sync behavior. All configured values must match existing structures within your ConnectWise deployment.

    ConnectWise Integration Settings

    • Integration Enabled: Enables all MSPControl-to-ConnectWise automation. Must be toggled on to activate any downstream functionality.
    • API Url: The base URL for your ConnectWise API environment. Typically includes versioned path (e.g. /v4_6_release/apis/3.0).
    • Client Id: A ConnectWise-issued application ID used for authentication.
    • Company Id: The ConnectWise company account name associated with your API keys and data scope.
    • Private Key / Public Key: Secure authentication credentials generated in ConnectWise. These must be kept secret and are not shown in the interface.

    ConnectWise Integration Settings

    Dashboard Widget Settings

    • Base Tickets Url: A URL template pointing to ConnectWise ticket pages. Must include [TICKET_NUMBER] placeholder for runtime substitution (e.g. ...request.rails?service_recid=[TICKET_NUMBER]).
    • Default Date Range: Sets the timeframe (e.g. Last 30 Days) used when displaying dashboard metrics about recent ConnectWise tickets.

    Dashboard Widget Settings

    Incident Ticket Settings

    Defines the behavior for generating incident tickets from alert data.

    • Board Name: ConnectWise service board used for security or monitoring incidents (e.g. SOC).
    • Type Name: High-level classification (e.g. Defender), must match a ConnectWise ticket type.
    • SubType Name: Further categorization (e.g. Incident), supporting downstream sorting/reporting.
    • Budget Hours: Time estimate for resolving the ticket (e.g. 0.50 hours).
    • Auto-Close Enabled: If selected, the ticket will be auto-closed after MSPControl receives a resolution trigger.

    Incident Ticket Settings

    Mailboxes Space Report Settings

    • Board Name: Service board where mailbox quota-related tasks are created (e.g. Preventive Maintenance).
    • Type / SubType Name: Ticket classification. These values (e.g. User and Email) must reflect your ConnectWise structure.
    • Status: Initial ticket state (e.g. New), controls visibility and flow assignment.
    • Budget Hours: SLA-based time estimate for task completion (e.g. 1.00).
    • Priority: ConnectWise priority name (e.g. Priority 4 – Low).
    • Auto-Close Enabled: Enables auto-resolution when flagged by automation.
    • Auto-Close Ticket Status Name: Status to apply upon auto-resolution (e.g. Closed).

    Mailboxes Space Report Settings

    Priority Matrix

    Maps ConnectWise priority names to standard urgency levels. You must ensure these values exist in ConnectWise. Example:

    • Emergency: Priority 1 - Emergency
    • High: Priority 2 - High
    • Medium: Priority 3 - Medium
    • Low: Priority 4 - Low
    • Informational: Priority 5 - No SLA

    Priority Matrix

    Recommendation Ticket Settings

    Used to create service tickets based on system-generated improvement suggestions or policy recommendations.

    • Board Name: Logical ConnectWise board for this type of ticket (e.g. Vulnerability Management).
    • Type Name: Task category used in ConnectWise (e.g. Defender Security Recommendation).
    • SubType Name: Further identifier (e.g. Vulnerability Management).
    • Budget Hours: Time budget (e.g. 0.50) for work planning and SLA reporting.

    Recommendation Ticket Settings

    Contacts Settings

    • Inactive Contact Ticket Status Name: The status assigned to tickets when a contact becomes inactive (e.g. Needs Review). Used for auditing or deprovisioning flows.
    • Portal Security Level Name: Security role applied to new portal contacts synced from MSPControl (e.g. User).
    • VIP Custom Field Name: The ConnectWise custom field name that flags a contact as VIP.

    Contacts Settings

    Risky User Detection Ticket Settings

    These settings control the creation of security alert tickets related to high-risk user behavior.

    • Board / Type / SubType: Must reflect ConnectWise ticketing structure (e.g. SOC, Security Alert, Risk Detection).
    • Budget Hours: Time estimate (e.g. 0.50).
    • Auto-Close Enabled: Whether to automatically resolve the ticket.
    • Close Ticket Status Name: Final status to apply (e.g. Closed).

    Risky User Detection Ticket Settings

    Expiring Apple MDM Push Certificate Ticket Settings

    • Board Name / Type / SubType: Identifiers used for expiring mobile device certs (e.g. Professional Services, Intune, Apple/Android Cert Expiration).
    • Budget Hours: Time estimate for resolving the ticket (e.g. 0.50 hours).
    • Auto-Close Enabled: Toggles automatic ticket resolution.
    • Auto-Close Ticket Status Name: Resolution status (e.g. Closed).

    Expiring Apple MDM Push Certificate Ticket Settings

    Windows Update Ticket Settings

    Three separate configurations control ticketing for Windows update-related issues:

    End of Servicing, SLA Not Met and Windows Isn’t Activated

    • Board / Type / SubType: Optional custom values for Windows lifecycle notices.
    • Budget Hours: Time estimate for resolving the ticket (e.g. 0.50 hours).
    • Move to Dispatcher after X Days: Sends to dispatcher if unresolved after X days.
    • Dispatcher Status Name: ConnectWise status name used for escalations.
    • Auto-Close Enabled / Status: Optional automatic resolution control.

    Windows Update Ticket SettingsWindows Update Ticket Settings

    Expiring Azure Applications Ticket Settings

    This section defines how MSPControl generates ConnectWise tickets when an Azure application’s certificate or token is about to expire. All fields must match ConnectWise configurations to ensure successful automation.

    • Board Name / Type / SubType: Determines where and how tickets are categorized (e.g. Professional Services, Application, Expiring App Cert or Token).
    • Budget Hours: Estimated resolution time (e.g. 1.00).
    • Priority Name: Optional priority level.
    • Auto-Close Enabled / Close Ticket Status Name: Controls whether ticket is closed automatically and the status to apply (e.g. Closed).

    Expiring Azure Applications Ticket Settings

    Note: All values (boards, types, subtypes, statuses) must exist in your ConnectWise instance. Inaccurate values will result in failed or missing tickets.

    UKG Terminated/Leave of Absence Ticket Settings

    This section configures tickets related to employee termination or leave of absence events from UKG systems. When such a status is detected, MSPControl generates a service ticket in ConnectWise for manual or automated offboarding workflows.

    • Board Name: Target ConnectWise board where the termination or leave ticket should be logged (e.g. HR Operations, Service Desk). Must match your board configuration.
    • Type Name: Optional category for the task (e.g. Termination, Leave) based on your ConnectWise setup.
    • SubType Name: Optional additional classification, often used to indicate context or urgency.
    • Budget Hours: Estimated time required for the ticket. Typically 0.00 if used only for auditing or notification.
    • Auto-Close Enabled: If checked, the ticket will automatically close once all termination logic completes (e.g. user deactivation, access removal).

    UKG Terminated/Leave of Absence Ticket Settings

    Expiring GDAP Admin Relationships Ticket Settings

    Configures automation for tickets created when GDAP (Granular Delegated Admin Privileges) relationships in Microsoft cloud environments are nearing expiration. Ensures MSPs take timely action to re-establish access or notify clients.

    • Board Name: The service board where GDAP expiration tickets will be placed (e.g. Professional Services or Cloud Admin).
    • Type Name: Broad task category, typically Administrative for GDAP roles.
    • SubType Name: Further breakdown (e.g. Admin Relationship Expiring), helps identify and route expiration-specific tickets.
    • Status Name: Optional initial status if your workflow requires a stage-based review (e.g. Queued, Pending Renewal).
    • Budget Hours: Estimated time to resolve (e.g. 0.50 hours).
    • Priority Name: Optional ConnectWise priority (e.g. Priority 3 – Medium). Leave blank to use board defaults.
    • Auto-Close Enabled: Enables automatic ticket resolution if your integration logic completes renewal successfully.
    • Close Ticket Status Name: The final status used to mark the ticket complete (e.g. Closed).

    Expiring GDAP Admin Relationships Ticket Settings

    O365 Subscriptions Opportunity Settings

    Defines default handling of sales opportunities related to Microsoft 365 licensing.

    • Sales Rep Default Identity: ConnectWise identity name of the default rep assigned to O365 sales opportunities.
    • Opportunity WON / LOST Status Value: Status name to assign based on opportunity outcome.

    O365 Subscriptions Opportunity Settings

    Default Sync Settings

    Enables or disables automatic creation of ConnectWise tickets and synchronization of user/contact data for a range of security and monitoring events.

    • Enable Auto-Ticket Creation for Incidents
    • Enable Auto-Ticket Creation for High/Medium/Low Security Recommendations
    • DefaultAutoTicketCreationForRiskyUsersEnabled
    • DefaultAutoTicketCreationForRiskySignInsEnabled
    • Enable Auto-Ticket Creation for Risk Detections
    • Enable Auto-Ticket Creation for Expiring Apple MDM Push Certificates
    • Enable Auto-Ticket Creation for Security Compliance Baseline Policy
    • Enable Sync Contacts and Locations
    • Enable Auto-Ticket Creation for Email Security Alerts
    • Enable Auto-Ticket Creation for Domains DKIM Signature is not Configured

    Default Sync Settings

    Security Compliance Baseline Policy Ticket Settings

    This configuration creates tickets when a Microsoft Defender Security Baseline policy change or update is detected. It helps MSPs track configuration drift or enforce compliance standards via ConnectWise ticketing.

    • Board Name: Service board to handle compliance-related tickets (e.g. Vulnerability Management).
    • Type Name: Task classification (e.g. Azure Security Baseline) indicating the scope or category of the issue.
    • SubType Name: Further breakdown of the task type, usually used for routing or automation (e.g. Change).
    • Budget Hours: Estimated resolution time (e.g. 0.50).
    • Auto-Close Ticket Status Name: Status assigned when the ticket is auto-closed (e.g. Closed).

    Additional Scope Settings: These fields allow defining a separate board and classification set specifically for MDM (Mobile Device Management) policies:

    • Intune MDM User Scope Board Name: ConnectWise board used to track Intune-specific security enforcement (e.g. Professional Services).
    • Intune MDM User Scope Type Name: Task type related to Intune policy (e.g. Intune).
    • Intune MDM User Scope SubType Name: Sub-classification for this scope (e.g. Configuration).

    Security Compliance Baseline Policy Ticket Settings

    Email Security Alert Ticket Settings

    This section handles automatic ticket creation for detected email security issues (e.g. spoofing attempts, phishing detections). It enables MSPs to proactively respond to mail-related threats.

    • Board Name: Service board responsible for monitoring and handling email security alerts (e.g. SOC).
    • Type Name: Classification of the task (e.g. Security Alert).
    • SubType Name: Additional specification for ticket routing (e.g. Email Security).
    • Budget Hours: Estimated time to review and resolve the issue (e.g. 0.50).
    • Get Email Security Alerts Within Last X Days: The ticket creation logic will filter events based on this threshold (e.g. 30 days).

    Email Security Alert Ticket Settings

    Database Connection

    This section stores the database connection string used by MSPControl to retrieve or sync ticket and opportunity data. The string is masked for security reasons and should be entered in a format supported by your underlying ConnectWise integration logic.

    Database Connection

    Tickets

    Specifies how MSPControl should interpret and process ConnectWise ticket data.

    • Boards: Comma-separated list of ConnectWise boards where tickets should be tracked. If left empty, tickets from all available boards may be included. Example: Professional Services,SOC,HelpDesk.
    • Closed Ticket Statuses: Determines which ticket statuses should be treated as closed in dashboards, SLA calculations, or syncs. If left blank, only ClosedFlag status will be considered closed.

    Tickets

    SLA Compliance

    Defines the minimum SLA (Service Level Agreement) compliance percentage required across tracked ConnectWise tickets.

    • Target SLA Compliance Rate %: Threshold used to measure ticket response performance, commonly set at 90% or higher.

    SLA Compliance

    Import Opportunities

    This section enables manual import of sales opportunities into ConnectWise from an external source.

    • Download Opportunities Template: Downloads a CSV file template with the required column structure.
    • Choose File: Uploads a filled-out template containing opportunities to import.
    • Import Opportunities: Triggers the import process and creates opportunities in ConnectWise using the uploaded data.

    Import Opportunities

    Domain Incorrect DNS Servers Ticket Settings

    Used to automatically create tickets when a domain is detected with incorrect DNS server configurations.

    • Board Name: ConnectWise board where such tickets are submitted (e.g. CommSec).
    • Type Name: Ticket category used to classify the alert (e.g. Unclassified Type).
    • SubType Name: Additional classification to support automation, filtering, or routing (e.g. Unclassified Subtype).
    • Budget Hours: Estimated work time to resolve or investigate (e.g. 1.00).
    • Priority Name: Optional setting to assign predefined priority (must match values in ConnectWise).
    • Auto-Close Enabled: If checked, the ticket will be closed automatically after resolution logic is applied.

    Domain Incorrect DNS Servers Ticket Settings

    Schedule Settings

    These parameters control the frequency and delay logic for background sync or scan operations related to ConnectWise integration.

    • Buffer Minutes: Time to wait before processing begins after a sync-triggering event. Helps avoid race conditions or ensure data availability (e.g. 5).
    • Interval Minutes: Defines how often the system should perform background sync or scan operations (e.g. 15).

    Domain DKIM/SPF/DMARC Configuration Ticket Settings

    Creates ConnectWise tickets when DKIM, SPF, or DMARC records are misconfigured or missing for a domain. Helps enforce email authentication best practices.

    • Board Name: ConnectWise service board where such security configuration issues are logged (e.g. CommSec).
    • Type Name: Ticket type category, typically aligned with the area of responsibility like Email.
    • SubType Name: Subcategory for filtering or reporting, such as Email Security Records.
    • Budget Hours: Time allocated for reviewing and fixing issues (e.g. 0.50).

    Domain DKIM/SPF/DMARC Configuration Ticket Settings

    Best Practices

    • All board names, type names, subtypes, statuses, and priorities must exactly match your ConnectWise configuration to avoid sync failures.
    • Use distinct boards and subtypes to categorize alerts and automation events separately from human-created tickets.
    • Enable auto-close cautiously, ensuring you have validation logic or automation in place to guarantee completion before resolution.
    • Set appropriate budget hours per ticket type to help with reporting, SLA metrics, and labor forecasting in ConnectWise.
    • Use custom fields such as VIP or portal security roles to prioritize and segment ticket workflows.
    • For all sync triggers (email security, DKIM, app expiration, etc.), enable auto-ticketing only if the integration logic supports safe repeat handling or deduplication.
    • Regularly review and test ticket creation across scenarios (manual import, auto-detection, etc.) to ensure alignment with your evolving ConnectWise structure.

    ManageEngine ServiceDesk Plus Integration Policy

    This section allows administrators to configure integration between MSPControl and ManageEngine ServiceDesk Plus (SDP). When enabled, MSPControl can communicate with the ServiceDesk Plus API to support automation, ticket management, and synchronization workflows.

    ManageEngine ServiceDesk Plus Integration Policy

    Integration Settings

    • Integration Enabled: Activates the integration with ServiceDesk Plus. Must be checked for any API communication to occur.
    • API Domain URL: The base domain of the ServiceDesk Plus API endpoint. Typically follows the format https://sdpdomain.manageengine.com and is required for all ticketing or asset sync requests.
    • Accounts Server URL: The identity provider domain for authentication. By default, this is https://accounts.zoho.com, as SDP often leverages Zoho authentication services.

    SmileBack Integration Policy

    This section allows you to configure integration with SmileBack, a customer feedback system. When enabled, MSPControl can send ticket or service completion data to SmileBack, allowing clients to provide feedback and ratings.

    SmileBack Integration Policy

    Integration Settings

    • Integration Enabled: Enables or disables the SmileBack integration platform-wide.
    • User Name: The email address used to authenticate with SmileBack’s API.
    • Password: Password associated with the SmileBack user account. Used only for token retrieval.
    • Client ID: OAuth client identifier provided by SmileBack to authenticate API requests.
    • Client Secret: OAuth client secret used in conjunction with the Client ID to authorize access securely.

    Customer Account Profile Policy

    This section controls which customer profile fields are required during customer creation and editing, and defines default values for account attributes.

    Customer Account Profile Policy

    Customer Account Profile Settings

    This block is divided into two major subsections:

    Mandatory and Optional Fields

    Allows administrators to toggle whether each field is required (Mandatory) or can be left blank (Optional) when a new customer account is created or updated.

    • First Name / Last Name: Customer’s contact name. Optional by default, but often required for personalized communication.
    • Account Number: Internal identifier for the customer account. Can be auto-generated or manually input depending on your system needs.
    • Company Name: Legal or trade name of the customer’s organization. Recommended for business customers.
    • Secondary E-Mail: Backup contact email. Useful for escalation or recovery communications.
    • Street Address, City, Region (State), Postal Code: Full address used for billing, shipping, or localization of services. Often optional unless invoicing or compliance requires it.
    • Country: Typically used for localization and compliance with geo-specific policies (e.g. taxes, regulations).
    • Phone Number / Mobile Phone / Fax: Contact channels. Admins may require mobile numbers for SMS or phone-based notifications.
    Default Options for Account Attributes

    Predefines how newly created customer accounts behave.

    • Mail Format: Default email format for outbound messages. Options typically include HTML or Plain Text. HTML is recommended for richer formatting.
    • Status: Default status of the customer account (e.g. Active). Determines whether the customer can interact with services immediately upon creation.
    • Send Account Summary Letter: When enabled, triggers a summary email to be sent after account creation. You must configure the email content separately under Mail Templates > Account Summary Letter.

    Two-Factor Authentication

    This section allows enforcement of two-factor authentication for customer portal logins.

    • Two-Factor Provider: Choose the authentication method to be used (e.g., None, Google Authenticator, etc.). If left as None, 2FA will not be required.
    • Country: Optional field that can be pre-set to simplify customer registration. Used for geographic pre-filtering or localization logic.

    Reseller Account Profile Policy

    This policy defines the default field requirements and behavior of reseller accounts in MSPControl. Administrators can configure which fields are mandatory, set default attribute values, and apply optional security settings for all newly created or modified reseller accounts.

    Reseller Account Profile Policy Reseller Account Profile Policy

    Mandatory and Optional Fields

    Each profile attribute can be set as Mandatory or Optional. These settings control which fields must be filled out during reseller account creation or editing.

    • First Name / Last Name: Basic identification fields for the primary contact person.
    • Account Number: Internal tracking identifier; optional or required depending on workflow needs.
    • Company Name: The formal name of the reseller organization.
    • Secondary E-Mail: Optional email used for additional contact or backup communications.
    • Street Address, City, Region (State), Country, Postal Code: Used for billing, compliance, and regional account filtering. Country is often marked mandatory to enable localization.
    • Phone Number 1 / Mobile Phone / Fax: Standard contact methods. At least one should be enabled as mandatory if direct communication is expected.

    Default Options for Account Attributes

    • Mail Format: Defines the default email format for reseller account notifications. Typical values: Html or Text.
    • Status: Sets the default account state (Active, Disabled, etc.). This determines whether the account is usable immediately after creation.
    • Send Account Summary Letter: When checked, the system will dispatch an automated summary email to the reseller. Requires the template to be configured in Mail Templates > Account Summary Letter.

    Two-Factor Authentication

    • Two Factor Provider: Allows enabling of 2FA (e.g., via Authenticator apps or SMS). Set to <None> by default unless your security policy mandates multi-factor authentication.

    Country

    The country selector helps localize account preferences and restrict regional services or tax rules. This dropdown reflects all countries supported by the system.

    Peer Account Profile Policy

    This section configures rules for peer account creation, including required profile fields, default behavior, and 2FA options.

    Peer Account Profile Policy Peer Account Profile Policy

    Peer Account Profile Settings

    • Hide built-in Customer Admin Peer Role: When enabled, this setting hides the default peer role automatically assigned to peer accounts. Use this to enforce custom permission structures and reduce role clutter in UI.

     

    Mandatory and Optional Fields

    Use these toggles to control whether specific fields must be completed when peer accounts are created or edited. These rules apply across all interfaces (e.g. portal, API, admin UI).

    • First Name / Last Name: Required for identification and user visibility.
    • Company Name: Organization associated with the peer account. Useful for partner-linked workflows.
    • Secondary E-Mail: Optional fallback email address for notifications.
    • Street Address, City, Country, Region (State), Postal Code: Standard location fields. May be required for jurisdictional processing, automation, or reporting.
    • Phone Number 1 / Mobile Phone / Fax: Contact methods for alerts or admin communication. Enforce if automation depends on SMS or voice-based messaging.

     

    Default Options for Account Attributes

    • Mail Format: Sets whether peer account emails are sent in plain text or HTML by default. Use HTML if you include links, branding, or formatted data.
    • Status: Default account state on creation. Enabled accounts are active immediately; use Disabled for manual review processes.

     

    Two Factor Authentication

    • Two factor provider: Choose the 2FA method applied to peer logins (e.g. Email-based OTP). If set to None, no 2FA will be enforced unless overridden elsewhere.
    • Country: Default country used for region-aware settings (e.g. phone formatting, default language, or business logic tied to geography).

    Space Add-ons Policy

    This section governs behavior for managing add-ons assigned to hosting spaces. Add-ons can be tied to specific resources, service options, or external licensing components.

    Space Add-ons Policy

    Space Addons Policy

    • Enforce Ticket Number: When enabled, users must provide a valid ticket number to perform operations involving space add-ons. This ensures traceability and helps support auditing and approval workflows.

    Scheduling Groups Policy

    This section allows administrators to manage scheduling groups used for ticket routing, escalation, triage, and task allocation. Scheduling groups define how tickets and tasks are assigned to ConnectWise members based on specific rules, status mappings, and availability preferences. Each group can be customized with triggers, ownership behaviors, and Microsoft Teams integration logic.

    Scheduling Groups Policy Scheduling Groups Policy

    Group Configuration

    • Name: Label for the scheduling group, shown throughout UI and rule mappings.
    • Description: Internal note or purpose of the group, for documentation or filtering.
    • Type: Logical classification. Used to differentiate functional purpose (e.g. Initial Triage, Escalation, Lunch).
    • Is Subgroup: Marks this entry as part of a larger parent scheduling group.
    • Max Number Of Lunches At One Time: Used for Lunch type groups to restrict simultaneous absences.

    Board Inclusion Settings

    • Prefer Same Owner For Contact’s Tickets: Attempts to assign the same technician to multiple tickets from the same contact for consistency.
    • Use All Boards: Enables the group to apply across all available ConnectWise boards.
    • Excluded ConnectWise Boards: Select specific boards where this group should be excluded from ticket handling.

    Membership and Assignment

    • ConnectWise Members: Assign specific ConnectWise users who will be responsible for handling tickets in this group.
    • Requests: Define inbound request types or rules that should be processed by this group.
    • Route all unmatched Tasks to this Group: Ensures fallback behavior when no other group matches a task’s conditions.

    Scheduling Prioritization

    • Scheduling Status: Optional override for status mapping behavior in ConnectWise.
    • Send Teams Message to Affected Techs (by Scheduling Priority): Sends automatic Microsoft Teams notifications when priority triggers are met.
    • Scheduling Priority Subgroup: Optional subgroup definition used for splitting scheduling logic based on internal escalation levels.
    • Scheduling Priorities: Configuration space to define thresholds or rules for priority-based dispatching.

    Immediate Work Automation

    • Immediate Work Status: Default status applied to immediate work tickets.
    • Send Teams Message to Affected Techs (by Immediate Work Priority): Triggers alert based on immediate priority conditions.
    • Immediate Work Subgroup / After Hours Subgroup: Define alternative technician pools or rule sets for regular and off-hours handling.
    • Immediate Work Priorities: Optional logic mapping priorities to behavior or subgroup.

    Task Handling Options

    • Add Resolution Note if Closed: Automatically inserts closure comments when ticket is closed by this group.
    • Assign Owner: Sets a default technician if not already assigned.
    • Override Owner if Exists: Reassigns owner if different from group default.
    • Owner must be Checked-In: Prevents assignment to technicians not currently logged in or available.
    • Add as Ticket Resource: Adds assigned technician as a formal resource to the ConnectWise ticket.
    • Enter Scheduled Calendar Time: Inserts the event into calendar scheduling for traceability.

    Microsoft Teams Integration

    • Send Teams Message To Affected Techs: Sends a Teams alert when tickets are assigned or reassigned.
    • Teams Chat/Conversation Id: Defines which chat or conversation should be used for posting alerts.
    • Send Notification to the Teams Chat: Enables direct messaging into a specified Teams thread.
    • Add Internal Note to the ticket: Inserts a visible internal update for reference.

    Status Processing

    • Process the Following Statuses: Define the ticket statuses which should trigger this group’s logic. Empty means apply to all incoming tickets.

    Ticket Board Routing Policy

    This policy allows administrators to create custom rules that determine how incoming service requests are routed between ConnectWise boards based on request type, validation criteria, source boards, and company identifiers. These routing rules support granular automation of ticket management workflows.

    Ticket Board Routing Policy

    Edit Board Selector Rule

    Each rule can be configured by editing the following parameters:

    • Request: A descriptive title or keyword that defines what kind of service request the rule applies to. Example: Logon failures for admin users.
    • Validation: An optional expression or tag that may be used to confirm the rule’s applicability or to enhance automation logic.
    • Source Boards: One or more ConnectWise boards where the incoming ticket originates. Only tickets created on these boards are subject to the routing rule.
    • Destination Board: The target ConnectWise board to which qualifying tickets should be routed automatically.
    • Company: Optional field for filtering the rule to only apply when the ticket is related to a specific company.

     

    Ticket Board Routing Policy

    Policy List View

    The main view displays a list of all configured board routing policies, including:

    • Request: Rule label or condition trigger.
    • Validation: Condition expression (if used).
    • Source Boards: Boards from which tickets are routed.
    • Destination Board: Board where tickets will be routed to.
    • Company: Applies the rule to tickets tied to a specific company (if set).
    • Edit: Allows modification of existing rules via the Edit icon.

    Rules can be added via the Add button, and existing entries can be selected and removed using the Delete button at the bottom of the list.

    Skillset Definitions Policy

    The Skillset Definitions Policy page allows administrators to define and manage technical skill categories that can later be assigned to users. Each skillset supports tiered descriptions—ranging from Beginner to Expert—to reflect the expected proficiency level.

    Skillset Definitions Policy

    Skillset Definitions

    This section lists all existing skillsets along with their descriptions and provides access to create, edit, or delete entries.

    • Name: Title of the skillset category (e.g., Microsoft 365, Cybersecurity).
    • Description: General explanation of what this skillset covers. Appears in the overview list and helps contextualize the skill.
    • Beginner / Intermediate / Advanced / Expert Descriptions: Optional descriptions to define expectations and typical responsibilities for each skill level. These are used for internal reference during skill assignment and filtering.

    To add a new skillset, click the Create button. This opens the skillset creation modal, where each level’s description can be optionally filled.

    Skillset Definitions

    User Skills Management

    This panel displays a list of users and their assigned skill levels for each category. Use this interface to manage technician capabilities and availability for routing, task matching, or scheduling logic.

    • Members: Select a user from the system to assign skills.
    • Assigned Skills: Lists selected skillsets and the corresponding proficiency level for each. Skills are selected via dropdown per user.

    User Skills Management

    Location IP Addresses Sync Policy

    This policy defines how IP address data from MSPControl is synchronized with IPBan, a third-party tool used to block or allow network access based on IP activity. Synchronization includes both allocated and unallocated IP addresses from the platform’s internal location database.

    Location IP Addresses Sync Policy

    Sync IPs Whitelist with IPBan

    • Enable IpBan: Master toggle to activate or disable synchronization between MSPControl and IPBan.
    • IpBan Server Address: URL or IP of the IPBan server where IP lists will be transmitted.
    • IpBan UserName / Password: Credentials used to authenticate the MSPControl system with IPBan. Password is masked for security.
    • Sync Allocated IPs Whitelist with IPBan: When enabled, all IP addresses currently assigned to devices or services in MSPControl will be whitelisted in IPBan.
    • Sync Unallocated IPs Whitelist with IPBan: Also syncs unused or reserved IPs to IPBan, allowing broader control over IP access lists.
    • Send new Device IP Addresses to IPBan Realtime: If checked, newly added device IPs are immediately pushed to IPBan without delay.

    IP Address Expiration

    • IP Address Expiration Enabled: Activates automatic expiry of whitelisted IPs in IPBan after a defined time period.
    • Days to Expire: Number of days after which an IP address will be removed from IPBan’s whitelist unless renewed.

    Scheduled Tasks Parameters Policy

    This section defines and configures synchronization behavior for scheduled tasks within MSPControl, especially for environments integrating Microsoft 365 or Azure AD. The settings govern task parallelism, synchronization scope, conflict resolution logic, and operational schedule.

    Scheduled Tasks Parameters Policy

    Task Execution Parameters

    • Maximum number of simultaneously running tasks: Defines the concurrency limit to avoid overloading system resources. Useful in large tenant scenarios where multiple sync operations can overlap.
    • Email addresses to notify: One or more recipients (comma-separated) who receive task completion, error, or status emails.
    • Task name: Label identifying the synchronization job (e.g., “Office 365 User Account Synchronization”). This name is used in logs and dashboards.

     

    Synchronization Scope

    • Sync users / groups / licenses: Toggle synchronization of user identities, groups, and license assignments between on-premises AD and AAD.
    • Sync users attributes and roles: Enables attribute-level sync for user records, including custom fields and group roles. Optionally use test mode before full deployment.
    • Sync email addresses: Includes aliases, SMTP records, and proxy addresses.
    • Sync unmatched primary emails: Ensures email alignment across systems for unique identifiers.
    • Sync domains: Synchronizes tenant-registered domains used across accounts.
    • Repair Subscriptions quantity: Optionally corrects mismatched or over-assigned subscription counts.
    • Sync Azure budgets: Aligns Azure cost management budgets to synced entities.
    • Sync administrative units: Includes role- and scope-based sync of admin units.

    Conflict and Cleanup Logic

    • Solve Attributes sync Conflict per user: Determines which source wins in case of attribute mismatches:
      • AD User Wins conflict: On-prem data has priority
      • AAD User Wins conflict: Cloud version overrides on-prem
    • Remove orphaned distribution lists: Cleans unused or unlinked distribution lists.
    • Delete unmatched users / groups: Prunes records that no longer exist in source systems.

    Schedule and Execution

    • Schedule: Defines how often the task runs (e.g., Daily).
    • Start Time: When the job starts (24-hour format).
    • Enabled: Master switch to activate or pause task execution.
    • Priority: Execution importance (Normal, High, etc.) — useful for queueing systems.
    • Min Severity for Write to Audit log: Controls the log verbosity (e.g., Information and more).
    • Max Execution Time: Timeout in units (e.g., 1 day). Prevents runaway tasks.

    Best Practices for General Policies in MSPControl

    When configuring MSPControl policies, consistency and accuracy are critical for long-term stability, auditability, and automation compatibility. Below are cross-policy best practices:

    General Configuration

    • Ensure all name fields (Board, Type, SubType, etc.) strictly match values defined in external systems like ConnectWise or ManageEngine to avoid sync errors.
    • Use clear, descriptive labels for task names, ticket types, or skillsets — they help identify rules in logs and dashboards.
    • Favor unified naming conventions across policies (e.g., lowercase for board names, consistent time estimates for Budget Hours).

    Automation and Sync Recommendations

    • Always test synchronization jobs in isolated environments before deploying globally (e.g., use test mode in Azure sync or mock validation rules in board routing).
    • Use auto-close statuses and expiration flags wherever available to reduce stale tickets or IP entries.
    • Define conflict resolution logic explicitly to prevent data drifts (e.g., AD wins vs AAD wins).

    Security and Access Control

    • Restrict API credentials and secure integration endpoints (ConnectWise, SmileBack, IPBan) with minimal scopes.
    • Avoid leaving optional fields blank if they are used for filtering or routing (e.g., priority names in ticket settings).

    Usability and Maintenance

    • Document skillsets and group policies clearly with level-based criteria (Beginner to Expert).
    • Assign members to scheduling groups and skillsets in a consistent format for transparency and auditability.
    • Review old task configurations, policies, and routing logic quarterly for accuracy and redundancy.

    Integration-Specific Tips

    • In ConnectWise, use explicit ticket status and board mapping for each policy. Don’t rely on defaults.
    • In ManageEngine, verify both API and account server URLs are valid and reachable before enabling integration.
    • In SmileBack, credentials should be rotated periodically and scoped to feedback-specific roles.

    Following these best practices ensures that your MSPControl instance remains resilient, predictable, and optimized for growth across user, client, and system integrations.

    Boost efficiency and profitability with MSPControl.

    No credit card required for free, limited license.